Re: Re: SPGiST versus hot standby - question about conflict resolution rules

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Re: SPGiST versus hot standby - question about conflict resolution rules
Date: 2012-08-03 17:14:31
Message-ID: 20141.1344014071@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-08-03 17:23:37 Re: WIP pgindent replacement
Previous Message Alvaro Herrera 2012-08-03 16:55:30 Re: Word-smithing doc changes