| 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().
| 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 |
| 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 |