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

From Tom Lane
Subject Re: Remembering bug #6123
Date
Msg-id 13110.1326400297@sss.pgh.pa.us
Whole thread Raw
In response to Re: Remembering bug #6123  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Remembering bug #6123  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Remembering bug #6123  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> 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.

You forgot to attach the patch, but the approach seems totally Rube
Goldberg to me anyway.  Why not just fix heap_update/heap_delete to
return the additional information?  It's not like we don't whack their
parameter lists around regularly.

Rather than having three output parameters to support the case, I'm
a bit inclined to merge them into a single-purpose struct type.
But that's mostly cosmetic.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Remembering bug #6123
Next
From: "Kevin Grittner"
Date:
Subject: Re: Remembering bug #6123