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. +
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? |