Re: Feature Request - DDL deployment with logical replication - Mailing list pgsql-hackers

From Konstantin Knizhnik
Subject Re: Feature Request - DDL deployment with logical replication
Date
Msg-id e4fbfdd9-e4df-374f-f99f-2f031e5e70cf@postgrespro.ru
Whole thread Raw
In response to Feature Request - DDL deployment with logical replication  (Jeremy Finzel <finzelj@gmail.com>)
Responses Re: Feature Request - DDL deployment with logical replication  (Chris Travers <chris.travers@adjust.com>)
Re: Feature Request - DDL deployment with logical replication  (Jeremy Finzel <finzelj@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench doc typos
Next
From: Edmund Horner
Date:
Subject: Re: pgbench doc typos