Re: Add CREATE support to event triggers - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Add CREATE support to event triggers
Date
Msg-id 20141127132347.GB16294@momjian.us
Whole thread Raw
In response to Re: Add CREATE support to event triggers  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, Nov 26, 2014 at 09:01:13PM -0500, Stephen Frost wrote:
> * Alvaro Herrera (alvherre@2ndquadrant.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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: What exactly is our CRC algorithm?
Next
From: Bruce Momjian
Date:
Subject: Re: [PATCH] HINT: pg_hba.conf changed since last config reload