Re: SUBSCRIPTIONS and pg_upgrade

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers@postgresql.org
Date: 2017-04-12T02:56:12Z
Lists: pgsql-hackers
On 4/10/17 20:55, Stephen Frost wrote:
>> Proposal: Dump all subscriptions in DISABLED state.  Remove current
>> pg_dump --no-subscription-connect option.
> I like this idea in general, I'm just not sure if it's the right answer
> when we're talking about pg_upgrade.  At a minimum, if we go with this
> approach, we should produce a warning when subscriptions exist during
> the pg_upgrade that the user will need to go re-enable them.

It's not clear what to do with a subscription after a dump/restore or a
pg_upgrade anyway.  You can't just continue streaming where you left
off.  Most likely, you will want to truncate the target tables and
resync them.  In some cases, you might just accept the data gap and
continue streaming at the current state.  But in any case you'll need to
decide based on what you're actually doing.  Just telling the user, turn
it back on and you're ready to go isn't necessarily the right answer.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. pg_dump: Always dump subscriptions NOCONNECT

  2. pg_dump: Dump subscriptions by default