Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby
От | Michael Paquier |
---|---|
Тема | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby |
Дата | |
Msg-id | CAB7nPqTdBf5N-YcyviRJDWFXTJN3g1W0KLDieNv4aW-bpSM7xQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Re: BUG #13685: Archiving while idle every
archive_timeout with wal_level hot_standby
|
Список | pgsql-hackers |
On Tue, Feb 9, 2016 at 2:24 PM, Amit Kapila <amit.kapila16@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
В списке pgsql-hackers по дате отправления: