|From:||Jeremy Finzel <finzelj(at)gmail(dot)com>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Cc:||PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Feature Request - DDL deployment with logical replication|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Fri, Mar 30, 2018 at 10:16 AM, Peter Eisentraut <
> On 3/29/18 13:21, Jeremy Finzel wrote:
> > 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?
> I think nobody has completely figured this out yet. Whatever is in
> pglogical and bdr and similar external projects are the best current
> compromises. But they have lots of problems, so I don't know if anyone
> is ready to propose something for in core yet.
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
IMO, it would be an acceptable and good first step to provide a function
that will replicate a SQL command through the replication stream at the
right point, even if there is still no automation around it.
|Next Message||Tom Lane||2018-03-30 17:04:20||BRIN FSM vacuuming questions|
|Previous Message||Ildus Kurbangaliev||2018-03-30 16:50:45||Re: [HACKERS] Custom compression methods|