Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures
Date
Msg-id CABUevEytQVaOOhGdoh0D7hGwe3fuKcRF6NthsSW7ww04EmtFgQ@mail.gmail.com
Whole thread Raw
In response to Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers


On Tue, Dec 20, 2022 at 5:40 AM Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Dec 20, 2022 at 09:01:02AM +0900, Michael Paquier wrote:
> Yeah, my mind was considering as well yesterday the addition of a note
> in the docs about something among these lines, so fine by me.

And applied that, after tweaking a few tiny things on a last lookup
with a catversion bump.  Note that the example has been moved at the
bottom of the table for these functions, which is more consistent with
the surroundings.


Hi!

Caught this thread late. To me, pg_dissect_walfile_name() is a really strange name for a function. Grepping our I code I see the term dissect s used somewhere inside the regex code and exactly zero instances elsewhere. Which is why I definitely didn't recognize the term...

Wouldn't something like pg_split_walfile_name() be a lot more consistent with the rest of our names?

//Magnus

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Use get_call_result_type() more widely
Next
From: Tom Lane
Date:
Subject: Re: Use get_call_result_type() more widely