Re: Proposal: Conflict log history table for Logical Replication

On Thu, 25 Jun 2026 at 19:15, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> PFA, updated version of the patch, fixes all the comments of V57

Currently, I have a use case where I would like to clean up conflict
log records using a 'MERGE' statement.

Consider a system that has accumulated conflict records over several
days or weeks. Some of those conflicts have already been resolved, and
in the meantime, a number of tables have been removed from the
publication, dropped on the subscriber, or are otherwise no longer
part of logical replication. However, the corresponding conflict log
records remain in the conflict log table.

One way to clean up such stale entries is to compare the 'relid'
stored in the conflict log table with 'pg_class' and delete rows whose
relations no longer exist. For example:
MERGE INTO pg_conflict.pg_conflict_log_16404 AS cl
USING pg_class AS c
ON (cl.relid = c.oid)
WHEN NOT MATCHED BY SOURCE THEN
DELETE;
However, this fails with:
ERROR: cannot modify or insert data into conflict log table
"pg_conflict_log_16404"
DETAIL: Conflict log tables are system-managed and only support
cleanup using DELETE or TRUNCATE.

Although this 'MERGE' only performs a 'DELETE', it is still rejected.

Is this restriction intentional? I can understand if supporting
'MERGE' is considered out of scope for this patch, but I wanted to
check whether rejecting a delete-only 'MERGE' is an intentional design
decision. If so, perhaps support for this use case could be considered
in a future version.

Regards,
Vignesh