Re: Re: SPGiST versus hot standby - question about conflict resolution rules
От | Tom Lane |
---|---|
Тема | Re: Re: SPGiST versus hot standby - question about conflict resolution rules |
Дата | |
Msg-id | 20141.1344014071@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: SPGiST versus hot standby - question about conflict resolution rules (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: Re: SPGiST versus hot standby - question about conflict resolution rules
|
Список | pgsql-hackers |
Noah Misch <noah@leadboat.com> writes: > On Thu, Aug 02, 2012 at 02:49:45PM -0400, Tom Lane wrote: >> * In spgRedoVacuumRedirect, call ResolveRecoveryConflictWithSnapshot >> with the newest-redirect XID. > There's an obsolete comment in spg_redo(). [ squint ... ] Comparing that to btree_redo, I realize that there's a bug in what I did yesterday: the ResolveRecoveryConflictWithSnapshot call has to happen before we call RestoreBkpBlocks, else the new state of the index page could be exposed to processes that need the old one. Will fix. I think the code in btree_redo could use a better (or any) comment about this point, too. >> But we still have to enforce the interlock against hot standby xacts. > We achieve that division of labor for XLOG_BTREE_DELETE by examining the old > contents before RestoreBkpBlocks(). This is safe, I think, because we only > examine the page when the system has running hot standby backends, and we only > allow hot standby connections when recovery has proceeded far enough to fix > all torn and ahead-of-EndRecPtr pages. Egad. That's seriously underdocumented as well. And I think it needs an explicit test that the page is actually older than the current WAL record, because it would otherwise be doing the wrong thing. regards, tom lane
В списке pgsql-hackers по дате отправления: