Re: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file)

At Tue, 4 Oct 2022 13:20:54 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> On Tue, Oct 4, 2022 at 12:11 PM Kyotaro Horiguchi
> <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> >
> > >
> > > > static uint32 minXlogTli = 0;
> >
> > I have found other three instances of this in xlog.c and
> > pg_receivewal.c. Do they worth fixing?
> >
> > (pg_upgarade.c has "uint32 tli/logid/segno but I'm not sure they need
> > to be "fixed". At least the segno is not a XLogSegNo.)
>
> There are quite a number of places where data types need to be fixed,
> see XLogFileNameById() callers. They are all being parsed as uint32
> and then used. I'm not sure if we want to fix all of them.
>
> I think I found that we can fix/refactor few WAL file related things:
>
> 1. 0001 replaces explicit WAL file parsing code with
> XLogFromFileName() and uses XLByteToSeg() in pg_resetwal.c. This was
> not done then (in PG 10) because the XLogFromFileName() wasn't
> accepting file size as an input parameter and pg_resetwal needed to
> use WAL file size from the controlfile. Thanks to the commit
> fc49e24fa69a15efacd5b8958115ed9c43c48f9a which added the
> wal_segsz_bytes parameter to XLogFromFileName(). This removes using
> extra variables in pg_resetwal.c and a bit of duplicate code too. It
> also replaces the explicit code with the XLByteToSeg() macro.

Looks good to me.

> 2. 0002 replaces MAXPGPATH with MAXFNAMELEN for WAL file names.
> MAXFNAMELEN (64 bytes) is typically meant to be used for all WAL file
> names across the code base. Because the WAL file names in postgres
> can't be bigger than 64 bytes, in fact, not more than XLOG_FNAME_LEN
> (24 bytes) but there are suffixes, timeline history files etc. To
> accommodate all of that MAXFNAMELEN is introduced. There are some
> places in the code base that still use MAXPGPATH (1024 bytes) for WAL
> file names which is an unnecessary wastage of stack memory. This makes
> code consistent across and saves a bit of space.

Looks reasonable, too. I don't find other instances of the same mistake.

> 3. 0003 replaces WAL file name calculation with XLogFileNameById() in
> pg_upgrade/controldata.c to be consistent across the code base. Note
> that this requires us to change the nextxlogfile size from hard-coded
> 25 bytes to MAXFNAMELEN (64 bytes).

I'm not sure I like this. In other places where XLogFileNameById() is
used, the buffer is known to store longer strings so MAXFNAMELEN is
reasonable. But we don't need to add useless 39 bytes here.
Therefore, even if I wanted to change it, I would replace it with
"XLOG_FNAME_LEN + 1".

> I'm attaching the v2 patch set.
>
> Thoughts?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center