On Sat, Dec 03, 2022 at 09:07:38AM +0530, Bharath Rupireddy wrote: > Yes, I removed those changes. Even if someone sees an offset of a > record within a WAL file elsewhere, they have the new utility function > (0002) pg_walfile_offset_lsn(). > > I'm attaching the v4 patch set for further review.
+ * Compute an LSN and timline ID given a WAL file name and decimal byte offset.
s/timline/timeline/, exactly two times
+ Datum values[2] = {0};
+ bool isnull[2] = {0};
I would not hardcode the number of attributes of the record returned.
Regarding pg_walfile_offset_lsn(), I am not sure that this is the best
move we can do as it is possible to compile a LSN from 0/0 with just a
segment number, say:
select '0/0'::pg_lsn + :segno * setting::int + :offset
from pg_settings where name = 'wal_segment_size';
+ resultTupleDesc = CreateTemplateTupleDesc(2);
+ TupleDescInitEntry(resultTupleDesc, (AttrNumber) 1, "lsn",
+ PG_LSNOID, -1, 0);
+ TupleDescInitEntry(resultTupleDesc, (AttrNumber) 2, "timeline_id",
+ INT4OID, -1, 0);
Let's use get_call_result_type() to get the TupleDesc and to avoid a
duplication between pg_proc.dat and this code.
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().
--
Michael
signature.asc
Description: PGP signature
