Re: Concurrency bug in UPDATE of partition-key

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Concurrency bug in UPDATE of partition-key
Дата
Msg-id CAA4eK1+rd-3NyG__8O0AvgL3Pk_ywp_Eh6Zb3Ki-SA0D0JWRkA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Concurrency bug in UPDATE of partition-key  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: Concurrency bug in UPDATE of partition-key  (Amit Khandekar <amitdkhan.pg@gmail.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Bulk Insert into PostgreSQL
Следующее
От: Arseny Sher
Дата:
Сообщение: Re: pgsql: Fix "base" snapshot handling in logical decoding