Re: Concurrency bug in UPDATE of partition-key
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Amit Khandekar <amitdkhan.pg@gmail.com>,
Dilip Kumar <dilipbalaut@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2018-06-30T13:50:15Z
Lists: pgsql-hackers
On Fri, Jun 29, 2018 at 11:22 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > I was a bit surprised by the new epqslot output argument being added, > and now I think I know why: we already have es_trig_tuple_slot, so > shouldn't we be using that here instead? Seems like it'd all be simpler ... > Hmm, maybe, but not sure if it will be simpler. The point is that we don't need to always return the epqslot, it will only be returned for the special case, so you might need to use an additional boolean variable to indicate when to fill the epqslot or someway indicate the same via es_trig_tuple_slot. I think even if we somehow do that, we need to do something additional like taking tuple from epqslot and store it in es_trig_tuple_slot as I am not sure if we can directly assign the slot returned by EvalPlanQual to es_trig_tuple_slot. OTOH, the approach used by Amit Khandekar seems somewhat better as you can directly return the slot returned by EvalPlanQual in the output parameter. IIUC, the same technique is already used by GetTupleForTrigger where it returns the epqslot in an additional parameter. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Allow using the updated tuple while moving it to a different partition.
- 40ca70ebcc9d 12.0 landed
- 0527df732beb 11.0 landed