Re: Add CREATE support to event triggers

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add CREATE support to event triggers
Date: 2014-11-27 13:23:47
Message-ID: 20141127132347.GB16294@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 26, 2014 at 09:01:13PM -0500, Stephen Frost wrote:
> * Alvaro Herrera (alvherre(at)2ndquadrant(dot)com) wrote:
> > Bruce Momjian wrote:
> > > How would replicating DDL handle cases where the master and slave
> > > servers have different major versions and the DDL is only supported by
> > > the Postgres version on the master server?
> >
> > Normally you would replicate between an older master and a newer
> > replica, so this shouldn't be an issue. I find it unlikely that we
> > would de-support some syntax that works in an older version: it would
> > break pg_dump, for one thing.

I like the idea of older master/new replica, but what about
bidirectional replication?

Would the create/alter/drop WAL locical structure remain consistent
across major versions, or would the code have to read at least one older
version? Would we limit it to one?

> While I tend to agree with you that it's not something we're likely to
> do, how would it break pg_dump? We have plenty of version-specific
> logic in pg_dump and we could certainly generate a different syntax in
> a newer version than we did in an older version, if the newer server was
> expecting something different. We've always held that you should use
> the version of pg_dump which match the server you are moving *to*, after
> all.

pg_upgrade avoids having to deal with major version changes by
leveraging pg_dump. Is it possible to have the new replica use the new
pg_dump to connect to the old master to get a CREATE command that it can
execute? Would that avoid having to ship CREATE syntax? What it
wouldn't help with is ALTER and DROP though. (We do have ALTER but I
think only for inheritance cases.)

> > In other words I view cross-version replication as a mechanism to
> > upgrade, not something that you would use permanently. Once you
> > finish upgrading, promote the newer server and ditch the old master.
>
> I agree with this also.

> > > If it would fail, does this limit the idea that logical replication
> > > allows major version-different replication?
> >
> > Not in my view, at least.
>
> I'm all for having logical replication be a way to do major version
> different replication (particularly for the purposes of upgrades), but
> it shouldn't mean we can never de-support a given syntax.
>
> As one example, we've discussed a few times removing certain table-level
> privileges on the basis that they practically mean you own the table.
> Perhaps that'll never actually happen, but if it does, logical
> replication would need to deal with it.

Should we just tell the user not to modify the database schema during
this period? Should we have a server mode which disables DDL?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2014-11-27 13:49:04 Re: [PATCH] HINT: pg_hba.conf changed since last config reload
Previous Message Bruce Momjian 2014-11-27 13:13:30 Re: What exactly is our CRC algorithm?