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 | CAB7nPqQrouh7VbRxeeMka3KKwcVuTBmtkEDL1nXKbZ=QU4B=DQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
On Sat, Jan 30, 2016 at 11:08 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Fri, Jan 29, 2016 at 9:13 PM, Michael Paquier wrote: >> Well, to put it short, I am just trying to find a way to make the >> backend skip unnecessary checkpoints on an idle system, which results >> in the following WAL pattern if system is completely idle: >> CHECKPOINT_ONLINE >> RUNNING_XACTS >> RUNNING_XACTS >> [etc..] >> >> The thing is that I am lost with the meaning of this condition to >> decide if a checkpoint should be skipped or not: >> if (prevPtr == ControlFile->checkPointCopy.redo && >> prevPtr / XLOG_SEG_SIZE == curInsert / XLOG_SEG_SIZE) >> { >> WALInsertLockRelease(); >> LWLockRelease(CheckpointLock); >> return; >> } >> As at least one standby snapshot is logged before the checkpoint >> record, the redo position is never going to match the previous insert >> LSN, so checkpoints will never be skipped if wal_level >= hot_standby. >> Skipping such unnecessary checkpoints is what you would like to >> address, no? Because that's what I would like to do here first. And >> once we got that right, we could think about addressing the case where >> WAL segments are forcibly archived for idle systems. > > I have put a bit more of brain power into that, and finished with the > patch attached. A new field called chkpProgressLSN is attached to > XLogCtl, which is to the current insert position of the checkpoint > when wal_level <= archive, or the LSN position of the standby snapshot > taken after a checkpoint. The bgwriter code is modified as well so as > it uses this progress LSN and compares it with the current insert LSN > to determine if a standby snapshot should be logged or not. On an > instance of Postgres completely idle, no useless checkpoints, and no > useless standby snapshots are generated anymore. Attached is an additional patch that I have used for my tests (should have sent that yesterday). This just shows up a couple of logs in the bgwriter and around checkpoint to see in more details their activity with not that much noise. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: