| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> | 
|---|---|
| To: | Noah Misch <noah(at)leadboat(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-16 09:19:30 | 
| Message-ID: | CA+hUKGLoV=wYa301GWaQUb7zb4cNE4QLqnik_QbHe-=3kpp=Ew@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Sun, Jan 16, 2022 at 8:12 PM Noah Misch <noah(at)leadboat(dot)com> wrote:
> For specifics of the kernel bug, see the attached test program.  In brief, the
> bug arises if one process is write()ing or pwrite()ing a file at about the
> same time that another process is read()ing or pread()ing the same.  POSIX
> says the reader should see the data as it existed before the write or the
> newly-written data.  On this kernel, the reader can see zeros instead.  That
> leads to the $SUBJECT failure.  PostgreSQL processes write out a given WAL
> block 20-30 times in ~10ms, and COMMIT PREPARED reads that block.  The writers
> aren't changing the bytes of interest to COMMIT PREPARED, but the zeros from
> the kernel bug yield the failure.  We could opt to work around that by writing
> only the not-already-written portion of a WAL block, but I doubt that's
> worthwhile unless it happens to be a performance win anyway.
>
> Separately, while I don't know of relevance to PostgreSQL, I was interested to
> see that CentOS 7 pwrite()/pread() fail to have the POSIX-required atomicity.
FWIW there was some related discussion over here:
https://www.postgresql.org/message-id/flat/17064-bb0d7904ef72add3%40postgresql.org
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-01-16 09:22:07 | pg_basebackup WAL streamer shutdown is bogus - leading to slow tests | 
| Previous Message | Thomas Munro | 2022-01-16 07:32:17 | Re: Large Pages and Super Pages for PostgreSQL |