as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
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, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
The PostgreSQL Global Development Group has released an update to all supported
versions of our database system, including 11.4, 10.9, 9.6.14, 9.5.18, and
9.4.23, as well as the second beta of PostgreSQL 12. This release fixes one
security issue and over 25 bugs since the previous cumulative update in May.
This release is made outside of the normal update release schedule as the
security vulnerability was determined to be critical enough to distribute the
fix as quickly as possible. Users who are running PostgreSQL 10, PostgreSQL 11,
or the PostgreSQL 12 beta should upgrade as soon as possible.
All other users should plan to apply this update at the next scheduled
downtime.
Release notes: https://www.postgresql.org/about/news/1949/
Security: 245629d4-991e-11e9-82aa-6cc21735f730
I've had to bump revision for several slaves here, but most will not
be rebuilt, except the -client slaves. Apologies for anyone having
to rebuild -clients unnecessarily, but it's not a heavy task- better safe
than sorry.
PR: ports/236156
Reported by: Andrew Dunstan (PostgreSQL), koobs, Dmitri Goutnik
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]
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
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
