Re: problem with RETURNING and update row movement

Поиск
Список
Период
Сортировка
От Etsuro Fujita
Тема Re: problem with RETURNING and update row movement
Дата
Msg-id CAPmGK15VsUF0a+FyNh1ZY2Wz08woAALYP10ZHe21AYRkuG9FdQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: problem with RETURNING and update row movement  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: problem with RETURNING and update row movement  (Amit Langote <amitlangote09@gmail.com>)
Список pgsql-hackers
On Mon, Aug 3, 2020 at 4:39 PM Amit Langote <amitlangote09@gmail.com> wrote:
> On Mon, Aug 3, 2020 at 2:54 PM Amit Langote <amitlangote09@gmail.com> wrote:
> > By the way, you'll need two adjustments to even get this example
> > working, one of which is a reported problem that system columns in
> > RETURNING list during an operation on partitioned table stopped
> > working in PG 12 [1] for which I've proposed a workaround (attached).
> > Another is that we forgot in our patch to "materialize" the virtual
> > tuple after conversion, which means slot_getsysattr() can't find it to
> > access system columns like xmin, etc.
>
> The only solution I could think of for this so far is this:
>
> +                   if (map)
> +                   {
> +                       orig_slot = execute_attr_map_slot(map,
> +                                                         res_slot,
> +                                                         orig_slot);
> +
> +                       /*
> +                        * A HACK to install system information into the just
> +                        * converted tuple so that RETURNING computes any
> +                        * system columns correctly. This would be the same
> +                        * information that would be present in the HeapTuple
> +                        * version of the tuple in res_slot.
> +                        */
> +                       tuple = ExecFetchSlotHeapTuple(orig_slot, true,
> +                                                      &should_free);
> +                       tuple->t_data->t_infomask &= ~(HEAP_XACT_MASK);
> +                       tuple->t_data->t_infomask2 &= ~(HEAP2_XACT_MASK);
> +                       tuple->t_data->t_infomask |= HEAP_XMAX_INVALID;
> +                       HeapTupleHeaderSetXmin(tuple->t_data,
> +                                              GetCurrentTransactionId());
> +                       HeapTupleHeaderSetCmin(tuple->t_data,
> +                                              estate->es_output_cid);
> +                       HeapTupleHeaderSetXmax(tuple->t_data, 0); /*
> for cleanliness */
> +                   }
> +                   /*
> +                    * Override tts_tableOid with the OID of the destination
> +                    * partition.
> +                    */
> +                   orig_slot->tts_tableOid =
> RelationGetRelid(destRel->ri_RelationDesc);
> +                   /* Also the TID. */
> +                   orig_slot->tts_tid = res_slot->tts_tid;
>
> ..but it might be too ugly :(.

Yeah, I think that would be a bit ugly, and actually, is not correct
in case of postgres_fdw foreign table, in which case Xmin and Cmin are
also set to 0 [2].  I think we should probably first address the
tableam issue that you pointed out, but I don't think I'm the right
person to do so.

Best regards,
Etsuro Fujita

[2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=da7d44b627ba839de32c9409aca659f60324de76



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

Предыдущее
От: Julien Rouhaud
Дата:
Сообщение: Re: [PG13] Planning (time + buffers) data structure in explain plan (format text)
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Yet another issue with step generation in partition pruning