Re: XLogReadRecord() error in XlogReadTwoPhaseData()

From: Noah Misch <noah(at)leadboat(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgbf(at)twiska(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: XLogReadRecord() error in XlogReadTwoPhaseData()
Date: 2022-01-21 03:30:42
Message-ID: 20220121033042.GA903845@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(at)leadboat(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-01-21 04:20:41 Re: Skipping logical replication transactions on subscriber side
Previous Message Amit Kapila 2022-01-21 03:20:23 Re: Skipping logical replication transactions on subscriber side