| From: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
|---|---|
| To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
| Subject: | Re: Proposal: Conflict log history table for Logical Replication |
| Date: | 2026-06-25 03:56:02 |
| Message-ID: | CAJpy0uC5x+Z=fvurvz=K8EYQSCQ1SCouR2LqiHS27Hp_Tzi6qw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Sharing my thoughts:
On Wed, Jun 24, 2026 at 7:27 PM Dilip Kumar <dilipbalaut(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2026-06-25 04:06:21 | In core use of RegisterXactCallback() and RegisterSubXactCallback() |
| Previous Message | Kyotaro Horiguchi | 2026-06-25 03:45:19 | Re: doc: fix pg_stat_autovacuum_scores threshold wording |