Horton

Re: XLogReadRecord() error in XlogReadTwoPhaseData()

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, pgbf@twiska.com, Tom Lane <tgl@sss.pgh.pa.us>, Michael Paquier <michael@paquier.xyz>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-01-23T22:26:53Z
Lists: pgsql-hackers 
Hi,

On 2022-01-24 09:42:13 +1300, Thomas Munro wrote:
> On Sun, Jan 23, 2022 at 7:52 AM Noah Misch <noah@leadboat.com> wrote:
> > Future work can benchmark the new behavior and, if it performs well, make
> > it unconditional in v15+.  I would expect performance to be unchanged or
> > slightly better, because the new behavior requests less futile work from
> > the OS.

I doubt it'll be generally applicable. Turning a write operation into a
read-write isn't free. Yes, often enough it's likely that the prior page is
still in cache, but I don't think we can rely on that in general.

It also just fundamentally locks us into never using O_DIRECT in anger. I
don't think that's a good direction.


> One detail is that wal_level=open_datasync, wal_senders=0,
> wal_level=minimal will panic, because O_DIRECT requires fs
> page-aligned access (and fails in various other ways on other OSes, eg
> expensive read-before-write every time).  That's an ultra-niche
> concern likely affecting nobody, especially when multiplied by the
> odds that anyone is using that stack at all (considering that
> streaming rep has apparently been borked for years on linux/sparc/ext4
> and nobody told us).

Seems like the patch should at least make this error out?

Greetings,

Andres Freund

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().