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