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

At Mon, 5 Dec 2022 13:13:23 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Mon, Dec 05, 2022 at 08:48:25AM +0530, Bharath Rupireddy wrote:
> > So, a SQL function pg_dissect_walfile_name (or some other better name)
> > given a WAL file name returns the tli and seg number. Then the
> > pg_walfile_offset_lsn can just be a SQL-defined function (in
> > system_functions.sql) using this new function and pg_settings. If this
> > understanding is correct, it looks good to me at this point.
> 
> I would do without the SQL function that looks at pg_settings, FWIW.

If that function may be called at a high frequency, SQL-defined one is
not suitable, but I don't think this function is used that way.  With
that premise, I would prefer SQL-defined as it is far simpler on its
face.

At Mon, 5 Dec 2022 10:03:55 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> Hence I would tend to let XLogFromFileName do the job, while having a
> SQL function that is just a thin wrapper around it that returns the
> segment TLI and its number, leaving the offset out of the equation as
> well as this new XLogIdFromFileName().

I don't think it could be problematic that the SQL-callable function
returns a bogus result for a wrong WAL filename in the correct
format. Specifically, I think that the function may return (0/0,0) for
"000000000000000000000000" since that behavior is completely
harmless. If we don't check logid, XLogFromFileName fits instead.

(If we assume that the file names are typed in letter-by-letter, I
 rather prefer to allow lower-case letters:p)

> > That said, let's also hear from others.
> 
> Sure.  Perhaps my set of suggestions will not get the majority,
> though..


regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center