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