Re: On-the-fly index tuple deletion vs. hot_standby - Mailing list pgsql-hackers

From Noah Misch
Subject Re: On-the-fly index tuple deletion vs. hot_standby
Date
Msg-id 20110616161430.GB13694@tornado.leadboat.com
Whole thread Raw
In response to Re: On-the-fly index tuple deletion vs. hot_standby  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Thu, Jun 16, 2011 at 04:53:41PM +0100, Simon Riggs wrote:
> On Thu, Jun 16, 2011 at 3:47 PM, Noah Misch <noah@leadboat.com> wrote:
> > Thanks. ?We still hit a conflict when btpo.xact == RecentGlobalXmin and the
> > standby has a transaction older than any master transaction. ?This happens
> > because the tests at nbtpage.c:704 and procarray.c:1843 both pass when the xid
> > exactly is that of the oldest standby transaction (line numbers as of git
> > cb94db91b). ?I only know this because the test script from my last message hits
> > this case; it might never get hit in real usage. ?Still, seems like a hole not
> > worth leaving. ?I think the most-correct fix is to TransactionIdRetreat the
> > btpo.xact before using it as xl_btree_reuse_page.lastestRemovedXid. ?btpo.xact
> > is the first known-safe xid, but latestRemovedXid is the last known-unsafe xmin.
> 
> I think you are pointing out another bug, rather than a problem in my
> last commit.
> 
> The bug was caused by assuming that the xid is a "latestRemovedXid",
> as is the case in the rest of Hot Standby, which masks the off-by-one
> error through poor use of terms.

Exactly.

> I agree with your suggested fix.

(Note that TransactionIdRetreat mutates its argument and returns nothing.)

Thanks,
nm


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: On-the-fly index tuple deletion vs. hot_standby
Next
From: "Ross J. Reedstrom"
Date:
Subject: Re: FOREIGN TABLE doc fix