Re: Support logical replication of DDLs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Support logical replication of DDLs
Date
Msg-id 3032112.1679865718@sss.pgh.pa.us
Whole thread Raw
In response to Re: Support logical replication of DDLs  (vignesh C <vignesh21@gmail.com>)
Responses Re: Support logical replication of DDLs  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Support logical replication of DDLs  (Zheng Li <zhengli10@gmail.com>)
List pgsql-hackers
vignesh C <vignesh21@gmail.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



pgsql-hackers by date:

Previous
From: Daniel Gustafsson
Date:
Subject: Re: Raising the SCRAM iteration count
Next
From: Andres Freund
Date:
Subject: Re: meson/msys2 fails with plperl/Strawberry