Re: on_error table, saving error info to a table

From: jian he <jian(dot)universality(at)gmail(dot)com>
To: Nishant Sharma <nishant(dot)sharma(at)enterprisedb(dot)com>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: on_error table, saving error info to a table
Date: 2026-05-06 08:08:33
Message-ID: CACJufxH_NbPuA+O5YR7xP4xDZ+iHkO2VFkddhrhBz+4-EUTp7w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 22, 2026 at 10:11 AM jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>
> Hi, V8 is attached.
>
> I've refactored a significant portion of the code. Now the new syntax is:
>
> COPY FROM (ON_ERROR TABLE, ERROR_TABLE err_tbl);
>
> We now produce a ModifyTableState and ResultRelInfo node, form the slot, and
> then use table_tuple_insert() + ExecInsertIndexTuples() to insert the error
> metadata into the ERROR_TABLE.
>
> This is very similar to the normal ExecInsert() path. Since the ERROR_TABLE is a
> user-defined table, we enforce the a lot of restriction,
> in CopyFromErrorTableCheck, we have comments like:
> +

Actually, We can export ExecInsert, construct a ModifyTableContext,
and let ExecInsert do the remaining job.
This would be neater.

V9-0001: Export ExecInsert, ExecSetupTransitionCaptureState,
fireBSTriggers, fireASTrigger.
v9-0002: Introduce a (ModifyTableContext *) field in CopyFromStateData.
Initialize all useful subordinate structures, including such as
ModifyTableState, EState, and ModifyTableState->ResultRelInfo. Set
cstate->escontext->details_wanted to true to ensure that all input conversion
error metadata is captured in cstate->escontext. Use this metadata to construct
a TupleTableSlot, and then delegate the remaining processing to ExecInsert.

Before calling ExecInsert() to insert error metadata into the ERROR_TABLE, we
must first populate a ModifyTableState, similar to how it is done in
ExecInitModifyTable.

ERROR_TABLE currently cannot be a partitioned table there is no need to call
ExecSetupPartitionTupleRouting. ERROR_TABLE cannot be a foreign table,
ExecInitModifyTable foreign table related initialization handling is not needed.
ERROR_TABLE does not support Row-Level Security (RLS), we do not need to handle
ModifyTable->withCheckOptionLists. For the INSERT code path, we also do not need
to worry about EvalPlanQual.

By comparing side-by-side with ExecInitModifyTable, it is ok to populate the
necessary information for the ERROR_TABLE using the following functions:
ExecInitRangeTable, ExecInitResultRelation, ExecOpenIndices, and
CheckValidResultRel.
This will allow the ERROR_TABLE to safely use ExecInsert().

--
jian
https://www.enterprisedb.com/

Attachment Content-Type Size
v9-0002-COPY-FROM-on_error-table-error_table-errtbl.patch text/x-patch 50.7 KB
v9-0001-export-ExecInsert-and-other-friends-function.patch text/x-patch 6.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Anthonin Bonnefoy 2026-05-06 08:13:57 Re: Server crash: Use-after-free in AfterTriggerEndQuery()
Previous Message Chao Li 2026-05-06 07:57:51 Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with broken old server