Hi Jeremy,
> My whole point is that in most architectures, DBAs decide to deploy the same
> SQL on providers and subscribers. Yes it isn't perfect, but IMO, it is very
> helpful to try to automate that idea, as opposed to trying to actually
> replicate DDL at the low level. The latter is better, yes, but seems to
> have proven extremely difficult. Hence, why you see the advent of functions
> to pipe DDL through the replication stream.
>
The community is currently working on in the current commitfest to try
and get logical decoding of 2PC in into the core.
Once something like that gets in, for a majority of subset of DDLs
(which works inside transaction blocks), one of the use cases of that
functionality could be to trap these DDLs and convert them into
implicit 2PC commands. Details need to be worked out, but we would get
all the logical replication cluster nodes in sync with each other and
issue a PREPARE transaction involving this DDL on all nodes in the
logical replication cluster. If any of the nodes is not able to
successfully prepare this DDL, then we can rollback or else commit the
2PC, thus moving the entire logical cluster consistently in terms of
schema changes.
Regards,
Nikhils
--
Nikhil Sontakke http://www.2ndQuadrant.com/
PostgreSQL/Postgres-XL Development, 24x7 Support, Training & Services
