Robert Haas <robertmh...@gmail.com> writes:
> 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.
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
