On Tue, Feb 9, 2016 at 2:24 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > Do you see any benefit in allowing checkpoints for such cases considering > bgwriter will anyway take care of logging standby snapshot for such > cases?
Well, the idea is to improve the system responsiveness. Imagine that the call to GetProgressRecPtr() is done within the exclusive lock portion, but that while scanning the WAL insert lock entries another backend is waiting to take a lock on them, and this backend is trying to insert the first record that updates the progress LSN since the last checkpoint. In this case the checkpoint would be skipped. However, imagine that such a record is able to get through it while scanning the progress values in the WAL insert locks, in which case a checkpoint would be generated. In any case, I think that we should try to get exclusive lock areas as small as possible if we have ways to do so. > I don't think there is any reasonable benefit to improve the situation of > idle-system check for checkpoint other than just including > standby snapshot WAL record. OTOH as checkpoint is not so seldom > operation, so allowing such a change should be okay, but I don't see > the need for same. I am not sure I understand your point here... -- Michael -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers