Re: Support logical replication of DDLs

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>

To: Zheng Li <zhengli10@gmail.com>

Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Dilip Kumar <dilipbalaut@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, rajesh singarapu <rajesh.rs0541@gmail.com>, Ajin Cherian <itsajin@gmail.com>, Hou, Zhijie/侯志杰 <houzj.fnst@fujitsu.com>

Date: 2022-05-07T04:08:43Z

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

On Fri, May 6, 2022 at 10:21 PM Zheng Li <zhengli10@gmail.com> wrote:
>
> > Attached is a set of two patches as an attempt to evaluate this approach.
> >
>
> Thanks for exploring this direction.
>
> I read the deparsing thread and your patch. Here is my thought:
> 1. The main concern on maintainability of the deparsing code still
> applies if we want to adapt it for DDL replication.
>

I agree that it adds to our maintainability effort, like every time we
enhance any DDL or add a new DDL that needs to be replicated, we
probably need to change the deparsing code. But OTOH this approach
seems to provide better flexibility. So, in the long run, maybe the
effort is worthwhile. I am not completely sure at this stage which
approach is better but I thought it is worth evaluating this approach
as Alvaro and Robert seem to prefer this idea.

> 2. The search_path and role still need to be handled, in the deparsing
> code. And I think it's actually more overhead to qualify every object
> compared to just logging the search_path and enforcing it on the apply
> worker.
>

But doing it in the deparsing code will have the benefit that the
other plugins won't have to develop similar logic.

-- 
With Regards,
Amit Kapila.