Обсуждение: pgsql: Add new pg_walsummary tool.
Add new pg_walsummary tool. This can dump the contents of the WAL summary files found in pg_wal/summaries. Normally, this shouldn't really be something anyone needs to do, but it may be needed for debugging problems with incremental backup, or could possibly be useful to external tools. Discussion: http://postgr.es/m/CA+Tgmobvqqj-DW9F7uUzT-cQqs6wcVb-Xhs=w=hzJnXSE-kRGw@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/ee1bfd168390bc843c6704d16e909692c0a79f27 Modified Files -------------- doc/src/sgml/ref/allfiles.sgml | 1 + doc/src/sgml/ref/pg_walsummary.sgml | 122 +++++++++++++++ doc/src/sgml/reference.sgml | 1 + src/bin/Makefile | 1 + src/bin/meson.build | 1 + src/bin/pg_walsummary/.gitignore | 1 + src/bin/pg_walsummary/Makefile | 48 ++++++ src/bin/pg_walsummary/meson.build | 30 ++++ src/bin/pg_walsummary/nls.mk | 6 + src/bin/pg_walsummary/pg_walsummary.c | 280 ++++++++++++++++++++++++++++++++++ src/bin/pg_walsummary/t/001_basic.pl | 19 +++ src/bin/pg_walsummary/t/002_blocks.pl | 88 +++++++++++ src/tools/pgindent/typedefs.list | 2 + 13 files changed, 600 insertions(+)
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. -- Robert Haas EDB: http://www.enterprisedb.com
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. -- Robert Haas EDB: http://www.enterprisedb.com
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
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