Re: COPY ON_CONFLICT TABLE; save duplicated record to another table.

From: Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>
To: jian he <jian(dot)universality(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY ON_CONFLICT TABLE; save duplicated record to another table.
Date: 2026-05-12 13:27:14
Message-ID: 49002699-1687-4f40-b5e6-680244435e81@uni-muenster.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Jian

On 12/05/2026 10:15, jian he wrote:
> Attached v3 fix this issue.

== closing relation too early ==

In noticed that in BeginCopyFrom() you open cstate->conflictRel and
close it after the CopyFromConflictTableCheck() call

cstate->conflictRel = table_open(conflictRelid, NoLock);
CopyFromConflictTableCheck(cstate);
table_close(cstate->conflictRel, NoLock);

But if we take a look at DoCopy(), the function CopyFrom() is called
immediately after a BeginCopyFrom() call, which now references to a
closed relation in cstate->conflictRel. I guess we should close the
relation in EndCopyFrom().

== redundant if blocks ==

These two if (cstate->opts.on_conflict == ONCONFLICT_TABLE) could be merged:

if (cstate->opts.on_conflict == ONCONFLICT_TABLE)
{
node->onConflictAction = ONCONFLICT_NOTHING;
node->canSetTag = true;
}

Assert(cstate->rel);
Assert(list_length(cstate->range_table) == 1);

if (cstate->opts.on_error != COPY_ON_ERROR_STOP)
Assert(cstate->escontext);

if (cstate->opts.on_conflict == ONCONFLICT_TABLE)
conflictslot = ExecInitExtraTupleSlot(estate,
RelationGetDescr(cstate->conflictRel),
&TTSOpsVirtual);

== comments ==
ON_CONFLCT > ON_CONFLICT
unqiue > unique

IIUC, it should be here (copy.h) "on conflict" instead of "on error", right?

char *on_conflictRel; /* on error, save error info to the table,
* table name */

Thanks!
Best, Jim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2026-05-12 13:42:32 Re: Add a greedy join search algorithm to handle large join problems
Previous Message Robert Haas 2026-05-12 12:56:26 Re: Bypassing cursors in postgres_fdw to enable parallel plans