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 | CAB7nPqTe_FzHg7gctybgff-1S_1OmcE5AAVsOVeisO=V3Z4FZA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: Re: BUG #13685: Archiving while idle every
archive_timeout with wal_level hot_standby
Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby |
Список | pgsql-hackers |
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. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: