Re: warning to publication created and wal_level is not set to logical
От | Robert Haas |
---|---|
Тема | Re: warning to publication created and wal_level is not set to logical |
Дата | |
Msg-id | CA+Tgmoayi4Z-kqo+bRyyCo5gLzHG4vQ8xjueZGJ6yOzzAxkkwA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: warning to publication created and wal_level is not set tological (David Fetter <david@fetter.org>) |
Ответы |
Re: warning to publication created and wal_level is not set to logical
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: