From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Remembering bug #6123 |
Date: | 2012-01-12 20:31:37 |
Message-ID: | 13110.1326400297@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2012-01-12 20:36:02 | Re: Remembering bug #6123 |
Previous Message | Kevin Grittner | 2012-01-12 20:29:13 | Re: Remembering bug #6123 |