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 self-executing. 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: http://www.postgresql.org/mailpref/pgsql-hackers