I tried to post this elsewhere but it got moderated, so retrying:
On Thu, Jan 11, 2024 at 1:49 PM Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Jan 11, 2024 at 12:56 PM Robert Haas <rhaas@postgresql.org> wrote:
> > Add new pg_walsummary tool.
>
> culicidae is unhappy with this, but I don't yet understand why. The output is:
>
> # Failed test 'stdout shows block 0 modified'
> # at t/002_blocks.pl line 85.
> # 'TS 1663, DB 5, REL 16384, FORK main: blocks 0..1'
> # doesn't match '(?^m:FORK main: block 0$)'
>
> The test is expecting block 0 to be modified, but block 1 to be
> unmodified, but here, both blocks are modified. That would maybe make
> sense if this machine had a really big block size, but that doesn't
> seem to be the case. Or, maybe the test has erred in failing to
> disable autovacuum -- though it does take other precautions to try to
> prevent that from interfering.
It's not autovacuum, the test is flaky. I ran it in a loop locally
until it failed, and then ran pg_waldump, finding this:
rmgr: Heap len (rec/tot): 73/ 8249, tx: 738, lsn:
0/0158AEE8, prev 0/01588EB8, desc: UPDATE old_xmax: 738, old_off: 2,
old_infobits: [], flags: 0x03, new_xmax: 0, new_off: 76, blkref #0:
rel 1663/5/16384 blk 1 FPW, blkref #1: rel 1663/5/16384 blk 0
I'm slightly puzzled, here. I would have expected that if I inserted a
bunch of records into the table and then updated one of them, the new
record would have gone into a new page at the end of the table, and
also that even if it didn't extend the relation, it would go into the
same page every time the test was run. But here the behavior seems to
be nondeterministic.
--
Robert Haas
EDB: http://www.enterprisedb.com