On Mon, Mar 25, 2019 at 10:15 AM David Fetter <da...@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
