From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | bharath(dot)rupireddyforpostgres(at)gmail(dot)com |
Cc: | masao(dot)fujii(at)oss(dot)nttdata(dot)com, nathandbossart(at)gmail(dot)com, sfrost(at)snowman(dot)net, bossartn(at)amazon(dot)com, rjuju123(at)gmail(dot)com, michael(at)paquier(dot)xyz, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Add checkpoint and redo LSN to LogCheckpointEnd log message |
Date: | 2022-02-01 06:27:56 |
Message-ID: | 20220201.152756.1157327790387186473.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Tue, 1 Feb 2022 10:08:04 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> On Tue, Feb 1, 2022 at 9:49 AM Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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 ordinary users 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
From | Date | Subject | |
---|---|---|---|
Next Message | Antonin Houska | 2022-02-01 06:45:06 | Re: XTS cipher mode for cluster file encryption |
Previous Message | Masahiko Sawada | 2022-02-01 06:17:04 | Re: Design of pg_stat_subscription_workers vs pgstats |