On Fri, Jan 28, 2022 at 08:43:36AM +0530, Bharath Rupireddy wrote: > 2022-01-28 03:06:10.213 UTC [2409486] LOG: checkpoint starting: > immediate force wait > 2022-01-28 03:06:10.257 UTC [2409486] LOG: checkpoint complete: > start=0/14D9510, end=0/14D9548; wrote 4 buffers (0.0%); 0 WAL file(s) > added, 0 removed, 0 recycled; write=0.007 s, sync=0.008 s, total=0.044 > s; sync files=3, longest=0.005 s, average=0.003 s; distance=0 kB, > estimate=0 kB > > 2022-01-28 03:06:42.254 UTC [2409486] LOG: checkpoint starting: > immediate force wait > 2022-01-28 03:06:42.279 UTC [2409486] LOG: checkpoint complete: > start=0/14DBDB8, end=0/14DBDF0; wrote 2 buffers (0.0%); 0 WAL file(s) > added, 0 removed, 0 recycled; write=0.004 s, sync=0.004 s, total=0.025 > s; sync files=2, longest=0.003 s, average=0.002 s; distance=10 kB, > estimate=10 kB
I know I voted for "start=%X/%X, end=%X/%X," but looking at this again, I wonder if it could be misleading. "start" is the redo location, and "end" is the location of the checkpoint record, but I could understand why someone might think that "start" is the location of the previous checkpoint record and "end" is the redo location of the new one. I think your original idea of "lsn=%X/%X, redo lsn=%X/%X" could be a good alternative. Іn any case, this patch is small and otherwise looks reasonable to me, so I am going to mark it as ready-for-committer. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com/
