On 25.10.2021 0:52, Peter Geoghegan wrote:
> On Sun, Oct 24, 2021 at 4:40 AM PG Bug reporting form
> <noreply@postgresql.org> wrote:
>> PostgreSQL version: 14.0
>> Operating system: FreeBSD 13.0-RELEASE
> PostgreSQL 14 is the first version where the default wal_sync_method
> is fdatasync() on FreeBSD -- though only with FreeBSD 13. See commit
> f900a79e. Perhaps that has something to do with the problem seen here.
To clarify: I had been running PostgreSQL 13.3 since the 18th of May
(upgraded from 13.2) until the upgrade to 14.0.
The REL_13_3 tag seems to include the change from f900a79e (matching the
commit message: ‘Like commit 576477e73c4, which did the same for Linux,
back-patch to all supported releases.’) and both the 13.3 package from
my package manager's cache and the 13.4 package available from FreeBSD
repositories at the moment uses fdatasync() as well:
[root@lincle-backup ~]# postgres --version
postgres (PostgreSQL) 13.3
[root@lincle-backup ~]# postgres --describe-config| grep wal_sync_method
wal_sync_method sighup Write-Ahead Log / Settings ENUM
fdatasync Selects the method used for forcing WAL
updates to disk.
[root@lincle-backup ~]# postgres --version
postgres (PostgreSQL) 13.4
[root@lincle-backup ~]# postgres --describe-config| grep wal_sync_method
wal_sync_method sighup Write-Ahead Log / Settings ENUM
fdatasync Selects the method used for forcing WAL
updates to disk.
According to the logs I have (daily reports), there have been no crashes
or unclean shutdowns of PostgreSQL on the server since the database jail
re-creation time (August of 2014 or so).
Vacuum has been performed daily on all databases since at least around
2017 via the daily periodic script.
--
K. R.