Re: Support logical replication of DDLs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Ajin Cherian <itsajin(at)gmail(dot)com>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "wangw(dot)fnst(at)fujitsu(dot)com" <wangw(dot)fnst(at)fujitsu(dot)com>, Runqi Tian <runqidev(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, li jie <ggysxcq(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Japin Li <japinli(at)hotmail(dot)com>, rajesh singarapu <rajesh(dot)rs0541(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Zheng Li <zhengli10(at)gmail(dot)com>
Subject: Re: Support logical replication of DDLs
Date: 2023-03-26 21:21:58
Message-ID: 3032112.1679865718@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

vignesh C <vignesh21(at)gmail(dot)com> writes:
> [ YA patch set ]

I spent some time looking through this thread to try to get a sense
of the state of things, and I came away quite depressed. The patchset
has ballooned to over 2MB, which is a couple orders of magnitude
larger than anyone could hope to meaningfully review from scratch.
Despite that, it seems that there are fundamental semantics issues
remaining, not to mention clear-and-present security dangers, not
to mention TODO comments all over the code.

I'm also less than sold on the technical details, specifically
the notion of "let's translate utility parse trees into JSON and
send that down the wire". You can probably make that work for now,
but I wonder if it will be any more robust against cross-version
changes than just shipping the outfuncs.c representation. (Perhaps
it can be made more robust than the raw parse trees, but I see no
evidence that anyone's thought much about how.)

And TBH, I don't think that I quite believe the premise in the
first place. The whole point of using logical rather than physical
replication is that the subscriber installation(s) aren't exactly like
the publisher. Given that, how can we expect that automated DDL
replication is going to do the right thing often enough to be a useful
tool rather than a disastrous foot-gun? The more you expand the scope
of what gets replicated, the worse that problem becomes --- for
example, I don't buy for one second that "let's replicate roles"
is a credible solution for the problems that come from the roles
not being the same on publisher and subscriber.

I'm not sure how we get from here to a committable and useful feature,
but I don't think we're close to that yet, and I'm not sure that minor
iterations on a 2MB patchset will accomplish much. I'm afraid that
a whole lot of work is going to end up going down the drain, which
would be a shame because surely there are use-cases here.

I suggest taking a couple of steps back from the minutiae of the
patch, and spending some hard effort thinking about how the thing
would be controlled in a useful fashion (that is, a real design for
the filtering that was mentioned at the very outset), and about the
security issues, and about how we could get to a committable patch.

If you ask me, a committable initial patch could be at most about a
tenth the size of what's here, which means that the functionality
goals for the first version have to be stripped way back.

[ Now, where did I put my flameproof vest? ]

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Paquier 2023-03-27 01:27:42 Re: Binding Postgres to port 0 for testing
Previous Message Bryn Llewellyn 2023-03-26 20:16:06 Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-03-26 21:28:30 Re: meson/msys2 fails with plperl/Strawberry
Previous Message Daniel Gustafsson 2023-03-26 21:14:37 Re: Raising the SCRAM iteration count