| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
supported versions of our database system, including 11.2, 10.7, 9.6.12,
9.5.16, and 9.4.21. This release changes the behavior in how PostgreSQL
interfaces with `fsync()` and includes fixes for partitioning and over
70 other bugs that were reported over the past three months.
Users should plan to apply this update at the next scheduled downtime.
FreeBSD port adds OPTIONS knob to support LLVM JIT. [1]
Highlight: Change in behavior with fsync()
------------------------------------------
When available in an operating system and enabled in the configuration
file (which it is by default), PostgreSQL uses the kernel function
`fsync()` to help ensure that data is written to a disk. In some
operating systems that provide `fsync()`, when the kernel is unable to
write out the data, it returns a failure and flushes the data that was
supposed to be written from its data buffers.
This flushing operation has an unfortunate side-effect for PostgreSQL:
if PostgreSQL tries again to write the data to disk by again calling
`fsync()`, `fsync()` will report back that it succeeded, but the data
that PostgreSQL believed to be saved to the disk would not actually be
written. This presents a possible data corruption scenario.
This update modifies how PostgreSQL handles a `fsync()` failure:
PostgreSQL will no longer retry calling `fsync()` but instead will
panic. In this case, PostgreSQL can then replay the data from the
write-ahead log (WAL) to help ensure the data is written. While this may
appear to be a suboptimal solution, there are presently few alternatives
and, based on reports, the problem case occurs extremely rarely.
A new server parameter `data_sync_retry` has been added to manage this
behavior. If you are certain that your kernel does not discard dirty
data buffers in such scenarios, you can set `data_sync_retry` to `on` to
restore the old behavior.
Release Notes: https://www.postgresql.org/about/news/1920/
PR: 232490 [1]
Notes:
svn path=/head/; revision=492989
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
Notes:
svn path=/head/; revision=487272
|
|
|
|
|
|
|
| |
This round is @FreeBSD.org residents except teams.
Notes:
svn path=/head/; revision=453381
|
|
|
|
|
|
|
|
|
| |
...and make sure not to bump portrevision more than necessary.
POINTED OUT BY: Peter Laursen
Notes:
svn path=/head/; revision=450532
|
|
|
|
|
|
|
|
|
|
| |
Most of them were called things like postgresql10beta3-docs-10.b3
With hat: portmgr
Sponsored by: Absolight
Notes:
svn path=/head/; revision=448138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
supported versions of our database system, including 9.6.4, 9.5.8,
9.4.13, 9.3.18, and 9.2.22. This release fixes three security issues.
It also patches over 50 other bugs reported over the last three months.
Users who are affected by the below security issues should update as
soon as possible. Users affected by CVE-2017-7547
(https://access.redhat.com/security/cve/CVE-2017-7547) will need to
perform additional steps after upgrading to resolve the issue. Other
users should plan to update at the next convenient downtime.
URL: https://www.postgresql.org/about/news/1772/
Security: CVE-2017-7546, CVE-2017-7547, CVE-2017-7548
Notes:
svn path=/head/; revision=447678
|
|
|
|
|
|
|
| |
instead of expired postgresql91-docs/Makefile
Notes:
svn path=/head/; revision=423058
|
|
Please read the entry from 20160905 in UPDATING:
daemon user has changed to `postgres'
ICU is default on
Notes:
svn path=/head/; revision=421360
|