Two small bugs in guc.c

I investigated the report at [1]/messages/by-id/CAK30z9T9gaF_isNquccZxi7agXCSjPjMsFXiifmkfu4VpZguxw@mail.gmail.com about pg_file_settings not reporting
invalid values of "log_connections". It turns out it's broken for
PGC_BACKEND and PGC_SU_BACKEND parameters, but not other ones.
The cause is a bit of premature optimization in this logic:

* If a PGC_BACKEND or PGC_SU_BACKEND parameter is changed in
* the config file, we want to accept the new value in the
* postmaster (whence it will propagate to
* subsequently-started backends), but ignore it in existing
* backends. ...

Upon detecting that case, set_config_option just returns -1 immediately
without bothering to validate the value. It should check for invalid
input before returning -1, which we can mechanize with a one-line fix:

-                    return -1;
+                    changeVal = false;

While studying this, I also noted that the bit to prevent changes in
parallel workers seems seriously broken:

if (IsInParallelMode() && changeVal && action != GUC_ACTION_SAVE)
ereport(elevel,
(errcode(ERRCODE_INVALID_TRANSACTION_STATE),
errmsg("cannot set parameters during a parallel operation")));

This is evidently assuming that ereport() won't return, which seems
like a very dubious assumption given the various values that elevel
can have. Maybe it's accidentally true -- I don't recall any
reports of trouble here -- but it sure looks fragile.

Hence, proposed patch attached.

regards, tom lane

[1]: /messages/by-id/CAK30z9T9gaF_isNquccZxi7agXCSjPjMsFXiifmkfu4VpZguxw@mail.gmail.com