Re: XLogReadRecord() error in XlogReadTwoPhaseData() - Mailing list pgsql-hackers

From Andres Freund
Subject Re: XLogReadRecord() error in XlogReadTwoPhaseData()
Date
Msg-id 20220123222653.6njdffnjzz65kh6v@alap3.anarazel.de
Whole thread Raw
In response to Re: XLogReadRecord() error in XlogReadTwoPhaseData()  (Thomas Munro <thomas.munro@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_basebackup fsyncs some files despite --no-sync (was: Adding CI to our tree)
Next
From: Andrew Dunstan
Date:
Subject: Re: fairywren is generating bogus BASE_BACKUP commands