On Thu, Mar 24, 2022 at 03:22:11PM +0530, Bharath Rupireddy wrote:
>> > > > > Both seem still very long. I still am doubtful this level of detail is
>> > > > > appropriate. Seems more like a thing for a tracepoint or such. How about just
>> > > > > printing the time for the logical decoding operations in aggregate, without
>> > > > > breaking down into files, adding LSNs etc?
>> > > >
>> > > > The distinction that the patch makes right now is for snapshot and
>> > > > rewrite mapping files and it makes sense to have them separately.
>> > >
>> > > -1. The line also needs to be readable...
>> >
>> > IMHO, that's subjective. Even now, the existing
>> > "checkpoint/restartpoint complete" message has a good amount of info
>> > which makes it unreadable for some.
>> >
>> > The number of logical decoding files(snapshot and mapping) the
>> > checkpoint processed is a good metric to have in server logs along
>> > with the time it took for removing/syncing them. Thoughts?
I took another look at the example output, and I think I agree that logging
the total time for logical decoding operations is probably the best path
forward. This information would be enough to clue an administrator into
the possible causes of lengthy checkpoints, but it also wouldn't disrupt
the readability of the log statement too much.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
