Re: Proposal: Conflict log history table for Logical Replication
| От | shveta malik |
|---|---|
| Тема | Re: Proposal: Conflict log history table for Logical Replication |
| Дата | |
| Msg-id | CAJpy0uD0BOTE6U3aWY6VkC1ga0YtcA7GN_tM5xk=WwJe4PUm4A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Proposal: Conflict log history table for Logical Replication (Dilip Kumar <dilipbalaut@gmail.com>) |
| Ответы |
Re: Proposal: Conflict log history table for Logical Replication
|
| Список | pgsql-hackers |
On Sun, Dec 14, 2025 at 9:20 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
Thanks for the patch. Few comments:
1)
+ if (isTempNamespace(namespaceId))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("cannot create conflict log table \"%s\" in a temporary namespace",
+ conflictrel),
+ errhint("Use a permanent schema.")));
a)
Shall we use 'temporary schema' instead of 'temporary namespace'? See
other similar errors:
errmsg("cannot move objects into or out of temporary schemas")
errmsg("cannot create relations in temporary schemas of other
sessions"))
errmsg("cannot create temporary relation in non-temporary schema")
b)
Do we really need errhint here? It seems self-explanatory. If we
really want to specify HINT, shall we say:
"Specify a non-temporary schema for conflict log table."
2)
postgres=# alter subscription sub1 set (conflict_log_table='');
ERROR: conflict log table name cannot be empty
HINT: Provide a valid table name or omit the parameter.
My idea was to allow the above operation to enable users to reset the
conflict_log_table when the conflict log history is no longer needed.
Is there any other way to reset it, or is this intentionally not
supported?
3)
postgres=# alter subscription sub1 set (conflict_log_table=NULL);
ALTER SUBSCRIPTION
postgres=# alter subscription sub2 set (conflict_log_table=create);
ALTER SUBSCRIPTION
postgres=# \d
List of relations
Schema | Name | Type | Owner
--------+---------+-------+--------
public | create | table | shveta
public | null | table | shveta
It takes reserved keywords and creates tables with those names. It
should be restricted.
4)
postgres=# SELECT c.relname FROM pg_depend d JOIN pg_class c ON c.oid
= d.objid JOIN pg_subscription s ON s.oid = d.refobjid WHERE s.subname
= 'sub1';
relname
---------
clt
postgres=# select count(*) from pg_shdepend where refobjid = (select
oid from pg_subscription where subname='sub1');
count
-------
0
Since dependency between sub and clt is a dependency involving
shared-object, shouldn't the entry be in pg_shdepend? Or do we allow
such entries in pg_depend as well?
thanks
Shveta
В списке pgsql-hackers по дате отправления: