Re: Hot standby, RestoreBkpBlocks and cleanup locks
От | Heikki Linnakangas |
---|---|
Тема | Re: Hot standby, RestoreBkpBlocks and cleanup locks |
Дата | |
Msg-id | 496F6146.5040008@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Hot standby, RestoreBkpBlocks and cleanup locks (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Hot standby, RestoreBkpBlocks and cleanup locks
|
Список | pgsql-hackers |
Simon Riggs wrote: > The idea outlined before didn't deal with all call points for > RecordIsCleanupRecord(), so doesn't actually work. Hmm, grep finds two call points for that: > ! case RECOVERY_TARGET_PAUSE_CLEANUP: > ! /* > ! * Advance until we see a cleanup record, then pause. > ! */ > ! if (RecordIsCleanupRecord(record)) > ! pauseHere = true; > ! break; > ! and > + /* > + * Wait, kill or otherwise resolve any conflicts between > + * incoming cleanup records and user queries. This is the > + * main barrier that allows MVCC to work correctly when > + * running standby servers. Only need to do this if there > + * is a possibility that users may be active. > + */ > + if (reachedSafeStartPoint && RecordIsCleanupRecord(record)) > + ResolveRedoVisibilityConflicts(EndRecPtr, record); The second we can easily handle by getting rid of ResolveRedoVisibilityConflicts functions and making the redo-functions call XactResolveRecoveryConflicts when necessary. Is the first really useful? I would understand "advance until next cleanup record *that would block/kill queries*", but why would you want to advance until the next cleanup record? Anyway, if it is useful, you could do the pausing in XactResolveRecoveryConflicts, too. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: