At Fri, 05 Mar 2021 13:21:48 +0900 (JST), Kyotaro Horiguchi <horikyota....@gmail.com> wrote in > At Fri, 05 Mar 2021 13:13:04 +0900 (JST), Kyotaro Horiguchi > <horikyota....@gmail.com> wrote in > > At Thu, 04 Mar 2021 23:02:09 -0500, Tom Lane <t...@sss.pgh.pa.us> wrote in > > > Having said that, it's still true that this test has been stable in > > > the buildfarm. Andres explained what he had to perturb to make it > > > fail, so I'm still interested in what Horiguchi-san did to break it. > > > > CONFIGURE = '--enable-debug' '--enable-cassert' '--enable-tap-tests' > > '--enable-depend' '--enable-nls' '--with-icu' '--with-openssl' > > '--with-libxml' '--with-uuid=e2fs' '--with-tcl' '--with-llvm' > > '--prefix=/home/horiguti/bin/pgsql_work' > > 'LLVM_CONFIG=/usr/bin/llvm-config-64' 'CC=/usr/lib64/ccache/gcc' > > 'CLANG=/usr/lib64/ccache/clang' 'CFLAGS=-O0' '--with-wal-blocksize=16' > > > > the WAL block size might have affected. I'll recheck without it. > > Ok, I don't see the failure. It guess that the WAL records for the > last transaction crosses a block boundary with 8kB WAL blocks, but not > with 16kB blocks.
In the failure case with 16kB WAL blocks, tx538 ends with a commit record at 0/01648B98 and nothing follows (other than the recrods added after restart). In the successful case, tx538 ends at the same LSN and followed by INSERT@tx539 at0/1648CE0 up to INSERT_LEAF at 0/0165BFD8-1. So tx539 just fits inside the block (0x1648000-0x164BFFF). That amount of WAL must cross a 8kB bounary. Actually with 8kB blocks, tx538 ends at 0/0164B1A8 and tx539 starts at 0/0164B2A8 and ends at 0/0165E7C8, corsses a boundary at 0/0164C000 and 0/016E000. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
