> Hmm, that's a little nasty, because it's not showing up in the
> buildfarm. It appears from a little testing that the issue only
> manifests if you have fsync = on, which we generally don't on
> buildfarm animals.
right, "make check" does not encounter this because it runs
with fsync=off, as I mentioned at the top of the thread.
> That concerns me independently of this specific failure, because
> it calls into question how realistic our testing of things like
> fsync statistics really is.
I agree, the 3 tests in stats.sql that do this
SELECT current_setting('fsync') = 'off' OR some stats test
are skipping over the fsync counters test altogether.
Perhaps we should enable fsync for these specific parts
of the test? it's SIGHUP
> Anyway, back to the patch: there are multiple places in
> stats.sql that are effectively disabling tests if fsync = off,
> not only this one. Why does only this one need the exception?
> Should we be rethinking or tightening some of the others?
IIUC, this is only an issue for wal syncing
"""
postgres=# select n into t from generate_series(1, 10000) as n;
SELECT 10000
postgres=# checkpoint; checkpoint;
CHECKPOINT
CHECKPOINT
postgres=# SELECT sum(writes) AS writes, sum(fsyncs) AS fsyncs, object
FROM pg_stat_io
WHERE context = 'normal'
group by object;
writes | fsyncs | object
--------+--------+---------------
7 | 0 | wal
0 | | temp relation
79 | 32 | relation
(3 rows)
postgres=# show wal_sync_method ;
wal_sync_method
-----------------
open_datasync
(1 row)
"""
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_
--
Sami Imseih
Amazon Web Services (AWS)
