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.5, 9.5.9,
9.4.14, 9.3.19, and 9.2.23.
This release includes fixes that prevent a crash in pg_restore when
using parallel mode. It also patches over a few other bugs reported
since the last releases in August.
Additionally, in 9.4.14 only, there is a fix to an issue with walsenders
preventing primary-server shutdown unless immediate shutdown mode is used.
Users should plan to update at the next convenient downtime.
Bug Fixes and Improvements
This update also fixes a number of bugs reported in the last few weeks.
Some of these issues affect only version 9.6, but many affect all
supported versions:
* Show foreign tables in information_schema.table_privileges view.
This fix applies to new databases, see the release notes for the
procedure to apply the fix to an existing database.
* Correctly identify columns that are of a range type or domain type
over a composite type or domain type being searched for
* Prevent crash when passing fixed-length pass-by-reference data types
to parallel worker processes
* Change ecpg’s parser to allow RETURNING clauses without attached C
variables
* Change ecpg’s parser to recognize backslash continuation of C
preprocessor command lines
* Improve selection of compiler flags for PL/Perl on Windows
