Re: Proposal: Conflict log history table for Logical Replication
shveta malik <shveta.malik@gmail.com>
From: shveta malik <shveta.malik@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
shveta malik <shveta.malik@gmail.com>
Date: 2026-06-25T03:56:02Z
Lists: pgsql-hackers
Sharing my thoughts:
On Wed, Jun 24, 2026 at 7:27 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
>
> 1) I haven't yet added the test to cover the lock skip check in
> LockViewRecurse_walker[1]. Since we now allow locking on the conflict
> log table (CLT), it makes sense to acquire the lock even when it is
> accessed recursively via a view.
I think we shall get rid of the check in LockViewRecurse_context. We
should have consistent behaviour for both direct and recursive lock
through views for CLT.
> 2) Additionally, I haven't covered the error reported in
> ATSimplePermissions() yet. We need more thought on how a CLT
> permission error could actually be triggered in this function, given
> that a simple ALTER TABLE ADD COLUMN is already blocked by the check
> in RangeVarCallbackForAlterRelation().
IMO, check in ATSimplePermissions is needed. Please see the results below:
CREATE TABLESPACE backup_space LOCATION '/tmp/tmp_test';
postgres=# ALTER TABLE ALL IN TABLESPACE pg_default SET TABLESPACE backup_space;
ERROR: 42501: permission denied: "pg_conflict_log_16431" is a
conflict log table
DETAIL: Conflict log tables are system-managed tables for logical
replication conflicts.
LOCATION: ATSimplePermissions, tablecmds.c:6923
So, tablespace change as part of bulk-movement s blocked for CLT by
the concerned check. If I remove the concerned check in
ATSimplePermissions(), this is the behaviour:
postgres=# ALTER TABLE ALL IN TABLESPACE pg_default SET TABLESPACE backup_space;
ERROR: 42501: permission denied: "pg_conflict_log_16523" is a system catalog
LOCATION: ATSimplePermissions, tablecmds.c:6932
postgres=# set allow_system_table_mods=on;
SET
postgres=# ALTER TABLE ALL IN TABLESPACE pg_default SET TABLESPACE backup_space;
ALTER TABLE
CLT is protected by below existign check by default but if we enable
'allowSystemTableMods', it allows changing tablespace of CLT
if (!allowSystemTableMods && IsSystemRelation(rel))
ereport(ERROR,
(errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
errmsg("permission denied: \"%s\" is
a system catalog",
RelationGetRelationName(rel))));
OTOH, if I try to change tablespace of CLT table alone (and not bulk
change), I hit this error even when allow_system_table_mods is ON
(with concerned ATSimplePermissions check still removed):
postgres=# ALTER TABLE conf.pg_conflict_log_16523 SET TABLESPACE backup_space;
ERROR: 42501: permission denied: "pg_conflict_log_16523" is a
conflict log table
DETAIL: Conflict log tables are system-managed tables for logical
replication conflicts.
LOCATION: RangeVarCallbackForAlterRelation, tablecmds.c:19925
postgres=# show allow_system_table_mods;
allow_system_table_mods
-------------------------
on
(1 row)
So above (direct CLT tabelspace change) is still restricted. I feel we
should retain check of ATSimplePermissions, so that behaviour is
consistent for CLT for direct and bulk change command.
thanks
Shveta
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow logical replication conflicts to be logged to a table.
- a5918fddf10d master landed
-
Avoid orphaned objects dependencies
- 2fbb21170e90 19 (unreleased) cited