From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Hot Standby 0.2.1 |
Date: | 2009-09-21 19:52:30 |
Message-ID: | 1253562750.4449.98.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2009-09-21 at 14:01 +0100, Simon Riggs wrote:
> On Mon, 2009-09-21 at 13:50 +0300, Heikki Linnakangas wrote:
> > is this that we seem to be missing conflict
> > resolution for GiST index tuples deleted by the kill_prior_tuples
> > mechanism. Unless I'm missing something, we need similar handling there
> > that we have in b-tree.
>
> OK, I agree with that. Straightforward change. Thanks very much.
>
> I marked the comment to indicate that the handling for GIST and GIN
> indexes looked dubious to me also. I had the earlier "it is safe"
> comments but that was before we looked at the kill prior tuples issue.
ISTM I looked at this too quickly.
kill_prior_tuple is only ever set by these lines, after scan starts:
if (!scan->xactStartedInRecovery)
scan->kill_prior_tuple = scan->xs_hot_dead;
which is set in indexam.c, not within any particular am. So the coding,
as submitted, covers all index types, current and future.
AFAICS there is no bug, unless you have a test case or can explain
further?
Worth raising as a query because it forced me to re-check how GIST and
GIN work and am happy again now.
--
Simon Riggs www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-09-21 20:06:33 | Re: Hot Standby 0.2.1 |
Previous Message | Tom Lane | 2009-09-21 19:27:35 | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 |