Re: XLogReadRecord() error in XlogReadTwoPhaseData()

On Sun, Jan 23, 2022 at 7:52 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> Attached. With this, kittiwake has survived 8.5hr of 003_cic_2pc.pl. Without
> the patch, it failed many times, always within 1.3hr. For easier review, this
> patch uses the new behavior on all platforms. Before commit and back-patch, I
> plan to limit use of the new behavior to sparc Linux. 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.

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

I was +1 for the control file locking change in that other thread (I
view the atomicity stuff as Linux-realpolitik-vs-POSIX, not to mention
that we run Windows too, which requires separate analysis). I'm less
sure it makes sense to do anything to support the presumed bogus
zeroes bug for (probably) no real users, especially before we've even
reported it and heard some analysis, for example acceptance that it's
broken and confirmation that this really is just a sparc problem.