At Mon, 5 Dec 2022 13:13:23 +0900, Michael Paquier <mich...@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 <mich...@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
