Re: Concurrency bug in UPDATE of partition-key

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Concurrency bug in UPDATE of partition-key
Date: 2018-06-30 13:50:15
Message-ID: CAA4eK1+rd-3NyG__8O0AvgL3Pk_ywp_Eh6Zb3Ki-SA0D0JWRkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 29, 2018 at 11:22 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Arseny Sher 2018-06-30 15:00:21 Re: pgsql: Fix "base" snapshot handling in logical decoding
Previous Message Craig Ringer 2018-06-30 13:26:50 Re: Bulk Insert into PostgreSQL