I wrote:
> ... This doesn't actually work in the current system.
I have a solution for this, I think. I propose that guc.c only allow
custom PGC_POSTMASTER variables to be created during
process_shared_preload_libraries(). (The implementation for this
would involve exporting a bool flag that process_shared_preload_libraries
sets while it's running.) That would come down to two cases:
1. A loadable library is being preloaded into the postmaster. This
happens only at postmaster startup, so it's clearly okay to create
a PGC_POSTMASTER variable then.
2. A loadable library is being loaded during startup of a child process
in the EXEC_BACKEND case. Since the shared_preload_libraries list is
itself a PGC_POSTMASTER variable, it can't have been changed since
postmaster start. Therefore, the library we are loading is also present
in the postmaster and the no-change-after-start rule has been enforced
on the variable all along. We're just instantiating it in the current
process, and we can trust that the value we inherited matches other
processes.
You could break this if you tried hard enough, like replace a library
with a new version underneath a running EXEC_BACKEND system, where
the new copy creates a PGC_POSTMASTER variable that the original
didn't. But that requires superuser privileges so it's not a security
hazard, just a don't-do-that issue. (There are plenty of other ways
such a replacement could break things, anyhow.)
What this would mean is that a library that needs to define a
PGC_POSTMASTER variable would need to fail if loaded with an ordinary
LOAD command. The most graceful way to do that is for it to examine the
process_shared_preload_libraries_in_progress flag for itself in its
_PG_init hook, and if not set report a warning and exit without doing
anything. If it fails to do so, and control actually gets to the point
of guc.c having to reject the PGC_POSTMASTER variable creation, I think
we'd better make that be a FATAL error. The reason is that the
noncooperative library may be partially hooked into the backend already
and so its behavior is likely to be messed up.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
