From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SUBSCRIPTIONS and pg_upgrade |
Date: | 2017-02-19 10:06:51 |
Message-ID: | CA+TgmoYAyQeejX35qge9uKkdADVp+4WwEb9iyqLk8nM1xruMjA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 17, 2017 at 7:34 AM, Stephen Frost <sfrost(at)snowman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-02-19 10:13:27 | Re: Index corruption with CREATE INDEX CONCURRENTLY |
Previous Message | Robert Haas | 2017-02-19 09:55:00 | Re: SCRAM authentication, take three |