Re: Support logical replication of DDLs
Zheng Li <zhengli10@gmail.com>
From: Zheng Li <zhengli10@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
Peter Smith <smithpb2250@gmail.com>, Ajin Cherian <itsajin@gmail.com>, vignesh C <vignesh21@gmail.com>,
li jie <ggysxcq@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>,
"houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.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-17T04:13:09Z
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 →
-
Add a run_as_owner option to subscriptions.
- 482675987bcd 16.0 cited
-
Refactor pgoutput_change().
- da324d6cd45b 16.0 cited
-
Print the correct aliases for DML target tables in ruleutils.
- df931e9ab35b 11.20 landed
- c8a5f1685fb7 15.3 landed
- 4efb4f0d4878 13.11 landed
- 3dd287c14fac 12.15 landed
- 393430f57544 16.0 landed
- 14345f3c6a7b 14.8 landed
-
Fix object identity string for transforms
- 9a312562314a 16.0 landed
-
Add grantable MAINTAIN privilege and pg_maintain role.
- 60684dd834a2 16.0 cited
-
Get rid of recursion-marker values in enum AlterTableType
- 840ff5f451cd 16.0 cited
-
Release cache tuple when no longer needed
- ed0fbc8e5ac9 15.0 cited
-
Empty search_path in logical replication apply worker and walsender.
- 11da97024abb 14.0 cited
-
Refactor format_type APIs to be more modular
- a26116c6cbf4 11.0 cited
-
Use wrappers of PG_DETOAST_DATUM_PACKED() more.
- 3a0d473192b2 10.0 cited
> > I've implemented a prototype to allow replicated objects to have the > > same owner from the publisher in > > v69-0008-Allow-replicated-objects-to-have-the-same-owner-from.patch. > > > > I also think it would be a helpful addition for users.A few points Thanks for supporting this addition. > that come to my mind are: (a) Shouldn't the role have the same > privileges (for ex. rolbypassrls or rolsuper) on both sides before we > allow this? (b) Isn't it better to first have a replication of roles? > I think if we have (b) then it would be probably a bit easier because > if the subscription has allowed replicating roles and we can confirm > that the role is replicated then we don't need to worry about the > differences. Yes, having role replication will help further reduce the manual effort. But even if we don't end up doing role replication soon, I think we can still provide this subscription option (match_ddl_owner, off by default) and document that the same roles need to be on both sides for it to work. > Now, coming to implementation, won't it be better if we avoid sending > the owner to the subscriber unless it is changed for the replicated > command? Consider the current case of tables where we send schema only > if it is changed. This is not a direct mapping but it would be better > to avoid sending additional information and then process it on the > subscriber for each command. Right, we can do some optimization here: only send the owner for commands that create objects (CREATE TABLE/FUNCTION/INDEX etc.) Note that ALTER TABLE/OBJECT OWNER TO is replicated so we don't need to worry about owner change. Regards, Zane