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
-
pg_dump: Always dump subscriptions NOCONNECT
- a9254e675bde 10.0 landed
-
pg_dump: Dump subscriptions by default
- c31671f9b5f6 10.0 landed