Re: Remembering bug #6123 - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Remembering bug #6123
Date
Msg-id 4F0EED37020000250004473D@gw.wicourts.gov
Whole thread Raw
In response to Re: Remembering bug #6123  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Remembering bug #6123
Re: Remembering bug #6123
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> it needs to check the tuple's cmax [...]  And that means the patch
> will be a bit more invasive than this, because heap_update and
> heap_delete don't return that information at present.
I'm thinking that I could keep the test for: GetCurrentCommandId(false) != estate->es_output_cid
as a "first pass".  If that's true, I could use EvalPlanQualFetch()
to find the last version of the tuple, and generate the error if the
tuple's cmax != estate->es_output_cid.  I think, although I'm not
entirely sure, that EvalPlanQualFetch needs a little work to support
this usage.
Attached is a patch based on these thoughts.  Is it on the right
track?  I suspect I haven't got everything covered, but thought a
reality check was in order at this point.
It does pass regression tests, including the new ones I added.
-Kevin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgbench post-connection command
Next
From: "Kevin Grittner"
Date:
Subject: Re: Remembering bug #6123