Skip site navigation (1) Skip section navigation (2)

Re: Custom PGC_POSTMASTER GUC variables ... feasible?

From: "Alex Hunsaker" <badalex(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Custom PGC_POSTMASTER GUC variables ... feasible?
Date: 2009-01-03 19:52:15
Message-ID: 34d269d40901031152i187dbd8aue3c03243ac406946@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, Jan 3, 2009 at 09:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

In response to

Responses

pgsql-hackers by date

Next:From: Joe ConwayDate: 2009-01-03 20:00:22
Subject: Re: [BUGS] BUG #4599: bugfix for contrib/dblink module
Previous:From: Tom LaneDate: 2009-01-03 16:44:22
Subject: Re: reloptions and toast tables

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group