On Mon, Mar 25, 2019 at 10:15 AM David Fetter <david@fetter.org> wrote:
> > I do not believe this is practical either. GUC manipulation cannot
> > look at the catalogs.
>
> In this case, it really has to do something. Is setting GUCs a path so
> critical it can't take one branch?
No, but that has about zero to do with the actual problem that Tom is
describing.
> If, as I strongly suspect, no such circumstance exists, it should not
> be possible for someone to have both of those at once, however
> inconvenient it is for us to arrange it.
Uh, Tom already told you how it can happen. You just take a pg_dump
of an existing database, run initdb to create a new cluster, and then
try to restore the dump on the new cluster. That shouldn't fail just
because wal_level = 'logical' isn't configured yet. If it did, that
would be creating a huge booby-trap for users that doesn't exist
today. You can't just dismiss that as nothing. I think users have
every right to expect that a dump and restore is going to work without
preconfiguring things like wal_level -- it's bad enough that you
already have to struggle with things like encoding to get dumps to
restore properly. Adding more ways for dump restoration to fail is a
really bad idea.
Besides that, it is obviously impractical to stop somebody from
shutting down the server, changing wal_level, and then restarting the
server. Nor can you make all publications magically go away if
someone does that. Nor would it be a good idea if we could do that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
