Re: Add checkpoint and redo LSN to LogCheckpointEnd log message - Mailing list pgsql-hackers
From | Kyotaro Horiguchi |
---|---|
Subject | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message |
Date | |
Msg-id | 20220201.152756.1157327790387186473.horikyota.ntt@gmail.com Whole thread Raw |
In response to | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Responses |
Re: Add checkpoint and redo LSN to LogCheckpointEnd log message
|
List | pgsql-hackers |
At Tue, 1 Feb 2022 10:08:04 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in > On Tue, Feb 1, 2022 at 9:49 AM Fujii Masao <masao.fujii@oss.nttdata.com> wrote: > > > > My previous comment was confusing... Probably I understand why you tried to put this information in checkpoint log message.But I was suggesting to put that information at the end of log message instead of the beginning of it. Because ordinaryusers would be less interested in this LSN information than other ones like the number of buffers written. > > Actually, there's no strong reason to put LSN info at the beginning of > the message except that LSN/REDO LSN next to the > checkpoint/restartpoint complete would make the users understand the > LSN and REDO LSN belong to the checkpoint/restartpoint. Since this > wasn't a strong reason, I agree to keep it at the end. > > Modified in v8. > > [1] > 2022-02-01 04:34:17.657 UTC [3597073] LOG: checkpoint complete: wrote > 21 buffers (0.1%); 0 WAL file(s) added, 0 removed, 0 recycled; > write=0.004 s, sync=0.008 s, total=0.031 s; sync files=18, > longest=0.006 s, average=0.001 s; distance=77 kB, estimate=77 kB; > lsn=0/14D5AF0, redo lsn=0/14D5AB8 0001 looks good to me. I tend to agree to 0002. FWIW, I collected other user-facing usage of "location" as LSN. xlog.c:5965, 6128: (errmsg("recovery stopping before WAL location (LSN) \"%X/%X\"", xlog.c:6718: (errmsg("control file contains invalid checkpoint location"))); xlog.c:6846: (errmsg("starting point-in-time recovery to WAL location (LSN) \"%X/%X\"", xlog.c:6929: (errmsg("could not find redo location referenced by checkpoint record"), xlog.c:11298, 11300: (in backup-label) appendStringInfo(labelfile, "START WAL LOCATION: %X/%X (file %s)\n", appendStringInfo(labelfile, "CHECKPOINT LOCATION: %X/%X\n", (and corresponding reader-code) xlog,c:11791, 11793: (in backup history file) fprintf(fp, "START WAL LOCATION: %X/%X (file %s)\n", fprintf(fp, "STOP WAL LOCATION: %X/%X (file %s)\n", (and corresponding reader-code) repl_scanner.l:151: yyerror("invalid streaming start location"); pg_proc.dat: many function descriptions use "location" as LSN. pg_waldump.c:768,777,886,938,1029,1071,1083: printf(_(" -e, --end=RECPTR stop reading at WAL location RECPTR\n")); printf(_(" -s, --start=RECPTR start reading at WAL location RECPTR\n")); pg_log_error("could not parse end WAL location \"%s\"", pg_log_error("could not parse start WAL location \"%s\"", pg_log_error("start WAL location %X/%X is not inside file \"%s\"", pg_log_error("end WAL location %X/%X is not inside file \"%s\"", pg_log_error("no start WAL location given"); pg_basebackup.c:476, 615: (confusing with file/directory path..) pg_log_error("could not parse write-ahead log location \"%s\"", pg_log_error("could not parse write-ahead log location \"%s\"", pg_rewind.c:346: pg_log_info("servers diverged at WAL location %X/%X on timeline %u", pg_rewind/timeline.c:82: pg_log_error("Expected a write-ahead log switchpoint location."); regards. -- Kyotaro Horiguchi NTT Open Source Software Center
pgsql-hackers by date: