On Fri, Feb 17, 2017 at 7:34 AM, Stephen Frost <sfr...@snowman.net> wrote:
> I'm not entirely sure about the reasoning behind requiring a flag to
> include subscriptions in pg_dump output, as the documentation doesn't
> actually provide one, but if we are going to require that, shouldn't
> pg_upgrade use it, to make sure that the subscriptions are pulled
> forward to the upgraded cluster?

Subscriptions are different from other objects in that whether or not
you want them in your dump output depends on how you plan to use the
dump.  If your goal is to create a server to replace the original
server, you want the subscriptions.  If you goal is to take a static
copy of the data, you don't.  Subscriptions aren't really data in the
sense that table data is data, or even in the sense that functions are
data.  Granted, you can execute a function, but a subscription is

That having been said, I share your discomfort with not dumping these
by default.  I think it would be good to dump and restore them by
default, but maybe restore them in disabled mode as you suggest
downthread, and document that if you want them enabled you have to
turn them on after doing the restore.  Otherwise, you could have
logical replication start up before the dump restore even completes,
which seems like it could cause all sorts of problems.

Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to