Re: Feature Request - DDL deployment with logical replication

From: Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Feature Request - DDL deployment with logical replication
Date: 2018-03-30 07:26:16
Message-ID: e4fbfdd9-e4df-374f-f99f-2f031e5e70cf@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 29.03.2018 20:21, Jeremy Finzel wrote:
> Hello!
>
> I have not seen much discussion about what the plans are for being
> able to manage schema changes when using logical replication.  In our
> own infrastructure, mechanisms that have been provided to manage DDL
> statements at the same transactional point as they happen on the
> master have been immensely useful to us, such as replicate_ddl_command
> from pglogical.
>
> Although we are thrilled with some of the features already in logical
> replication, this missing feature is the #1 reason that we don't plan
> to take a serious look at built-in logical replication even for pg11,
> because we have been able to use pglogical with our own extension
> pgl_ddl_deploy in order to broadly deploy logical replication without
> serious overhauls to our SDLC process, having schema changes managed
> well.  We really want a mechanism to put through DDL changes at the
> same transactional point on the subscribers as we do on the
> publishers, which also answers any complexities around deploying
> master-first or slave-first in some interesting cases.
>
> Is there any particular vision for how the community might address
> this need in the future?
>
> Thank you!
> Jeremy

Our team in PostgresPro is also very interested in this discussion,
because we are using logical decoding in multimaster.
Right now in multimaster DDLs are replicated in this same way as in
pglogical, using "logical messages" with correspondent DDL statements.
There are a couple of problems related with this approach, for example
mix of DDL with DML (create table as...) which we have addressed in
multimaster.

As an alternative we have considered possibility to replicate updates of
catalog tables. In this case we need  to address the following issues:
1. Map OIDs
2. Perform direct manipulation with files (i.e. truncate, alter table,...)
3. Send invalidations

Looks like it will be not so easy to implement this approach because we
have to repeat or somehow reuse substantial part of executor code for
this DDL nodes.
And definitely this approach works only for Postgres-to-Postgres
replication.

So it will be very interesting for us to know roadmap for DDL support in
logical replication.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Edmund Horner 2018-03-30 07:30:51 Re: pgbench doc typos
Previous Message Fabien COELHO 2018-03-30 06:26:26 Re: pgbench doc typos