databases/py-sqlparse01 (0.1.x) is no longer needed since devel/py-twext depends on databases/py-sqlparse020 (0.2.0) now.
PR: 235966
Submitted by: Axel Rau <axel.rau@chaos1.de>
This is a quick release after 8.0.14 which fixes Bug #29249542, Bug #94004
on upstream (Group repl. doesn't work when IPv6 is disabled on OS)
More info on upstream: https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-15.html
While here, delete the no-more-needed warning from "pkg-message" since MySQL8.0 is GA.
Sponsored by: The FreeBSD Foundation
While in devel/double-conversion, order USExx clauses, and replace CMAKE_POSITION_INDEPENDENT_CODE with BUILD_SHARED_LIBS since shared libs should be a default
Update and bump databases/clickhouse
Approved by: portmgr blanket
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]
Sunpoet Po-Chuan Hsieh
Kevin Bowling
Jan Beich
Kurt Jaeger
Mahdi Mokhtari
Steve Wills
Dmitry Sivachenko
Baptiste Daroussin
Bernard Spil
Vanilla I. Shu
Danilo Egea Gondolfo
Mark Linimon
Muhammad Moinur Rahman
Timur I. Bakeyev
Yuri Victorovich
Antoine Brodin
Palle Girgensohn
Wen Heping