Horton

Re: XLogReadRecord() error in XlogReadTwoPhaseData()

Noah Misch <noah@leadboat.com>

View thread View on postgr.es
From: Noah Misch <noah@leadboat.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: pgbf@twiska.com, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-01-21T03:30:42Z
Lists: pgsql-hackers 
On Fri, Jan 21, 2022 at 08:34:22AM +1300, Thomas Munro wrote:
> On Mon, Jan 17, 2022 at 10:02 AM Noah Misch <noah@leadboat.com> wrote:
> > - Report a Debian bug for the sparc64+ext4 zeros problem.
> 
> I suspect that 027_stream_regress.pl hits this kernel bug with high
> probability[1].  I wonder if the owner of kittiwake and tadarida would
> consider setting up an xfs file system?  Or alternatively, since ext4
> didn't support concurrent writes until recently, I wonder if there is
> an option somewhere to turn the new concurrency stuff off, or failing
> that, if we could temporarily downgrade the kernel to an older version
> that does inode-level read/write locking.

If the write-only-new-bytes approach works, I think we'd want to revert those
changes.  Perhaps a cheaper stopgap is to make the affected tests skip on
sparc Linux.  Is that worth doing?  (Could even limit the skip to ext4,
e.g. by testing "df -x ext4 . >/dev/null".)

> [1] https://www.postgresql.org/message-id/CA%2BhUKG%2BeuZ%3Ddc27ZB%3Ds74x0q%3DzU%3D2%3Dvs8%2B6TkJoTUiCPUd2dQA%40mail.gmail.com

Commits

  1. Under has_wal_read_bug, skip recovery/t/032_relfilenode_reuse.pl.

  2. Under has_wal_read_bug, skip contrib/bloom/t/001_wal.pl.

  3. Use Test::Builder::todo_start(), replacing $::TODO.

  4. On sparc64+ext4, suppress test failures from known WAL read failure.

  5. Report any XLogReadRecord() error in XlogReadTwoPhaseData().