On Fri, Feb 17, 2017 at 09:33:32AM -0500, Stephen Frost wrote:
> Peter,
>
> * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> > On 2/16/17 21:04, Stephen Frost wrote:
> > > I'm not entirely sure about the reasoning behind requiring a flag to
> > > include subscriptions in pg_dump output,
> >
> > One reason is that pg_subscription is only readable by a superuser, so
> > we can't even dump them unless we're superuser.
>
> Sure, but that's true of roles and other things.. On a system with RLS,
> likely only the database superuser can actually read everything.
>
> > Also, restoring a subscription will immediately attempt to start
> > replication, which might be kind of surprising.
>
> Isn't that what the 'disabled' option is for? Also, when it comes to
> pg_upgrade, isn't that what you would probably want?
>
> Perhaps it shouldn't start immediately, but rather create them as
> disabled at first and then start them at the end of the restore.
>
> > We had pondered this issue extensively during early review. I don't
> > think we're all happy with the current behavior, but it's probably the
> > safest and easiest one for now.
> >
> > Better ideas are welcome.
>
> I don't think we can simply punt entirely on this, particularly for the
> pg_upgrade case. At the least, I think we should be exporting the
> subscriptions in a disabled fashion, so that at least the user *has*
> them in the backup, even if they aren't enabled. With pg_upgrade, I
> would think we'd want to have some option to tell pg_upgrade to include
> subscriptions, or to enable them afterwards if they're included but off
> by default.
>
> I've added it to the open items for PG10. Perhaps we can get some other
> input/suggestions on it.
[Action required within three days. This is a generic notification.]
The above-described topic is currently a PostgreSQL 10 open item. Peter,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.
[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com