Greetings, * Fujii Masao (masao.fu...@oss.nttdata.com) wrote: > On 2022/02/01 22:03, Bharath Rupireddy wrote: > >On Tue, Feb 1, 2022 at 11:58 AM Kyotaro Horiguchi > ><horikyota....@gmail.com> wrote: > >>>Modified in v8. > >> > >>0001 looks good to me. > > I found that CreateRestartPoint() already reported the redo lsn as follows > after emitting the restartpoint log message. To avoid duplicated logging of > the same information, we should update this code? > > ereport((log_checkpoints ? LOG : DEBUG2), > (errmsg("recovery restart point at %X/%X", > LSN_FORMAT_ARGS(lastCheckPoint.redo)), > xtime ? errdetail("Last completed transaction was at > log time %s.", > > timestamptz_to_str(xtime)) : 0)); > > This code reports lastCheckPoint.redo as redo lsn. OTOH, with the patch, > LogCheckpointEnd() reports ControlFile->checkPointCopy.redo. They may be > different, for example, when the current DB state is not > DB_IN_ARCHIVE_RECOVERY. In this case, which lsn should we report as redo lsn? > > + "lsn=%X/%X, redo lsn=%X/%X", > > Originally you proposed to use upper cases for "lsn". But the latest patch > uses the lower cases. Why? It seems better to use upper cases, i.e., LSN and > REDO LSN because LSN is basically used in other errmsg().
We do use 'lsn=' quite a bit in verify_nbtree.c already and lowercase is also what's in the various functions and views in the catalog in the database, of course. I don't see even one usage of "LSN=" in the tree today. We also use 'lsn %X/%X' in replorigindesc.c, xactdesc.c, xactdesc.c, tablesync.c, standby.c, parsexlog.c, then 'redo %X/%X' in xactdesc.c. xlog.c does have a number of "WAL location (LSN)", along with a bunch of other usages. logical.c uses both "LSN" and "lsn". worker.c uses "LSN". slot.c uses "restart_lsn". pg_rewind.c uses "WAL location" while pg_waldump.c uses, "lsn:", "WAL location", and "WAL record". Overall, we don't seem to be super consistent, but I'd say that 'lsn=' looks the best, to my eyes anyway, and isn't out of place in the code base. Lowercase seems to generally be more common overall. > >Attaching the above changes 0003 (0001 and 0002 remain the same). If > >the committer doesn't agree on the text or wording in 0003, I would > >like the 0001 and 0002 to be taken here and I can start a new thread > >for discussing 0003 separately. > > Personally I'm ok with 001, but regarding 0002 and 0003 patches, I'm not sure > if it's really worth replacing "location" with "lsn" there. BTW, the similar > idea was proposed at [1] before, but seems "location" was left as it was. > > [1] > https://postgr.es/m/20487.1494514...@sss.pgh.pa.us This discussion strikes me as sufficient reason to make the change, with the prior comment not really having all that much weight. When we're actually pretty consistent with one term, having random places where we are inconsistent leads people to be unsure about which way to go and then we end up having to have this discussion. Would be great to avoid having to have it again in the future. Thanks, Stephen
signature.asc
Description: PGP signature