On Sat, Jan 3, 2009 at 09:37, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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().
Sounds simple enough.
> 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.)
Right I agree this is a non-issue. For that matter if I really wanted
to muck with it I could just set
process_shared_preload_libraries_in_progress = true in my _PG_init
function. And I guess if anyone thinks thats a problem we can mark
the flag as static and only export a function for reading the value.
> 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.
Agreed.