aboutsummaryrefslogtreecommitdiff
path: root/databases/postgresql95-contrib
diff options
context:
space:
mode:
authorPalle Girgensohn <girgen@FreeBSD.org>2019-02-15 11:02:22 +0000
committerPalle Girgensohn <girgen@FreeBSD.org>2019-02-15 11:02:22 +0000
commitf7e9e29abb1593ce90e54df31cf7c327ef1e03cb (patch)
tree57fd167c04384663545f34f8218b5b573867a5c8 /databases/postgresql95-contrib
parentdabf99b4a4099852c10ac3730eb96f8f764ba8cc (diff)
downloadports-f7e9e29abb1593ce90e54df31cf7c327ef1e03cb.tar.gz
ports-f7e9e29abb1593ce90e54df31cf7c327ef1e03cb.zip
The PostgreSQL Global Development Group has released an update to all
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
Notes: svn path=/head/; revision=492989
Diffstat (limited to 'databases/postgresql95-contrib')
-rw-r--r--databases/postgresql95-contrib/Makefile2
1 files changed, 1 insertions, 1 deletions
diff --git a/databases/postgresql95-contrib/Makefile b/databases/postgresql95-contrib/Makefile
index 5e80b8e7cec4..760edb6a941d 100644
--- a/databases/postgresql95-contrib/Makefile
+++ b/databases/postgresql95-contrib/Makefile
@@ -2,7 +2,7 @@
# $FreeBSD$
PORTNAME= postgresql
-PORTREVISION= 1
+PORTREVISION= 0
CATEGORIES= databases
MAINTAINER= pgsql@FreeBSD.org