Re: Custom PGC_POSTMASTER GUC variables ... feasible?

In PG10.3, guc.c's init_custom_variables issues a FATAL error if an attempt
is made to define a custom PGC_POSTMASTER variable after startup (see
below), and that ERROR wouldn't be safe, in general.

But this means that if a user does:

CREATE EXTENSION anyExtensionThatDefinesA_PGC_POSTMASTER_Variable;

but forgets to add the extension to shared_preload_libraries first, then
said user will crash the server, rather than just getting an error message.
This is an easy mistake for a user to make, and a severe consequence. It
may even be considered a security hole if a malicious user can crash the
server so easily.

What were the possible failure scenarios that throwing a fatal error was
intended to avoid, i.e. what sort of "hooking into" is the comment below
referring to that was regarded as a fate worse than death?

If throwing just an ERROR level elog is truly a fate worse than FATAL, how
should the extension writer protect their users from crashing the server
when they make this mistake?

│8012 /*
│8013 * Only allow custom PGC_POSTMASTER variables to be
created during shared
│8014 * library preload; any later than that, we can't ensure
that the value
│8015 * doesn't change after startup. This is a fatal elog
if it happens; just
│8016 * erroring out isn't safe because we don't know what
the calling loadable
│8017 * module might already have hooked into.
│8018 */
B+>│8019 if (context == PGC_POSTMASTER &&
│8020 !process_shared_preload_libraries_in_progress)
│8021 elog(FATAL, "cannot create PGC_POSTMASTER
variables after startup");

--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html