Horton

Re: Support logical replication of DDLs

vignesh C <vignesh21@gmail.com>

View thread
From: vignesh C <vignesh21@gmail.com>
To: Peter Smith <smithpb2250@gmail.com>
Cc: Ajin Cherian <itsajin@gmail.com>, Zheng Li <zhengli10@gmail.com>, li jie <ggysxcq@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, "houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>, Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Japin Li <japinli@hotmail.com>, rajesh singarapu <rajesh.rs0541@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-02-10T16:31:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add a run_as_owner option to subscriptions.

  2. Refactor pgoutput_change().

  3. Print the correct aliases for DML target tables in ruleutils.

  4. Fix object identity string for transforms

  5. Add grantable MAINTAIN privilege and pg_maintain role.

  6. Get rid of recursion-marker values in enum AlterTableType

  7. Release cache tuple when no longer needed

  8. Empty search_path in logical replication apply worker and walsender.

  9. Refactor format_type APIs to be more modular

  10. Use wrappers of PG_DETOAST_DATUM_PACKED() more.

On Fri, 10 Feb 2023 at 21:50, vignesh C <vignesh21@gmail.com> wrote:
> The attached v68 version patch has the changes for the same.

I was not sure if we should support ddl replication of
create/alter/drop subscription commands as there might be some data
inconsistency issues in the following cases:
#node1 who is running in port 5432
create publication pub_node1 for all tables with ( PUBLISH = 'insert,
update, delete, truncate');

#node2 who is running in port 5433
create publication pub_node2 for all tables with(PUBLISH = 'insert,
update, delete, truncate', ddl = 'all');
create subscription sub_node2 connection 'dbname=postgres host=node1
port=5432' publication pub_node1;

#node3
create subscription sub_node3 connection 'dbname=postgres host=node2
port=5433 publication pub_node2;

#node1
create table t1(c1 int );

#node2
create table t1(c1 int);
alter subscription sub_node2 refresh publication;

# Additionally this command will be replicated to node3, creating a
subscription sub2_node2 in node3 which will subscribe data from node1
create subscription sub2_node2 connection 'dbname=postgres host=node1
port=5432' publication pub_node1;

After this any insert into t1 from node1 will be replicated to node2
and node3, additionally node2's replicated data(which was replicated
from node1) will also be sent to node3 causing inconsistency. If the
table has unique or primary key constraints, it will lead to an error.

Another option would be to replicate the create subscription in
disabled state and not support few ddl replication of alter
subscription which will connect to publisher like:
1) Alter subscription sub1 enable;
2) Alter subscription sub1 refresh publication;

But in this case also, we will be able to support few alter
subscription commands and not support few alter subscription commands.
I feel it is better that we do not need to support ddl replication of
create/alter/drop subscription command and let users handle the
subscription commands.
Thoughts?

Regards,
Vignesh