Re: warning to publication created and wal_level is not set to logical
От | Tom Lane |
---|---|
Тема | Re: warning to publication created and wal_level is not set to logical |
Дата | |
Msg-id | 20963.1553536412@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: warning to publication created and wal_level is not set to logical (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: warning to publication created and wal_level is not set tological
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > 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. To clarify, the problems with that are (1) Initial GUC settings are absorbed by the postmaster, which cannot examine catalogs *at all*. It is neither connected to any database nor allowed to participate in transactions. These are not things that will change. (2) wal_level is a global setting, but the catalogs we'd have to look at to discover the existence of a publication are per-database. Thus for example there is no reliable way for "ALTER SYSTEM SET wal_level" to detect whether publications exist in other databases of the cluster. (To say nothing of race conditions against concurrent publication creation commands.) Adding the dump/restore issue on top of that, it seems clear to me that we can't usefully prevent a conflicting setting of wal_level from being established. The best we can do is whine about it later. One idea that might be useful is to have walsenders refuse to transmit any logical-replication data if they see wal_level is too low. That would get users' attention pretty quickly. regards, tom lane
В списке pgsql-hackers по дате отправления: