Re: pg_walfile_name_offset can return inconsistent values - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_walfile_name_offset can return inconsistent values
Date
Msg-id ZU1Ln2vWjkqdEIpi@momjian.us
Whole thread Raw
In response to Re: pg_walfile_name_offset can return inconsistent values  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: pg_walfile_name_offset can return inconsistent values
Re: pg_walfile_name_offset can return inconsistent values
List pgsql-hackers
On Thu, Nov  9, 2023 at 09:49:48PM +0100, Matthias van de Meent wrote:
> > I have attached fix #1 as offset1.diff and fix #2 as offset2.diff.
> 
> I believe you got the references wrong; fix #1 looks like the output
> of offset2's changes, and fix #2 looks like the result of offset1's
> changes.

Sorry, I swaped them around when I realized the order I was posting them
in the email, and got it wrong.

> Either way, I think fix #1 is most correct (as was attached in
> offset2.diff, and quoted verbatim here), because that has no chance of
> having surprising underflowing behaviour when you use '0/0'::lsn as
> input.

Attached is the full patch that changes pg_walfile_name_offset() and
pg_walfile_name().  There is no need for doc changes.  We need to
document this as incompatible in case users are realying on the old
behavior for WAL archiving purposes.  If they want the old behavior they
need to check for an offset of zero and subtract one from the file name.

Can someone check that all other calls to XLByteToPrevSeg() are correct?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Improve WALRead() to suck data directly from WAL buffers when possible
Next
From: Nathan Bossart
Date:
Subject: Re: Atomic ops for unlogged LSN