Re: warning to publication created and wal_level is not set to logical

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Mar 25, 2019 at 10:15 AM David Fetter <david(at)fetter(dot)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