On Thu, Apr 10, 2025 at 06:45:36PM -0500, Sami Imseih wrote:
> IIUC, this is only an issue for wal syncing
Yes, good catch. I have missed this effect of issue_xlog_fsync(),
which has two callers. The first one in XLogWrite() never happens if
wal_sync_method is open_sync or open_datasync. The second call just
relies on the sync to be discarded internally by issue_xlog_fsync().
> so only the below test with object = 'wal' needs to be tightened
>
> SELECT sum(writes) AS writes, sum(fsyncs) AS fsyncs
> FROM pg_stat_io
> WHERE context = 'normal' AND object = 'wal' \gset io_sum_wal_normal_after_
My mistake here. Sorry about that.
SELECT current_setting('fsync') = 'off'
+ OR current_setting('wal_sync_method') NOT IN ('fdatasync', 'fsync', 'fsync_writethrough')
The code in xlog.c filters out the syncs for WAL_SYNC_METHOD_OPEN and
WAL_SYNC_METHOD_OPEN_DSYNC, wouldn't it be more consistent to do the
same in the code and the SQL test, using an IN clause with the two
values that block the syncs rather than a NOT IN clause with the three
values that allow the syncs? This translates to the attached, which
is the same as your patch, but this is more consistent with the code.
--
Michael
