On Sun, Dec 19, 2010 at 5:41 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> ... users IMO should not be concerned with custom_variable_classes at
> all. The only users that know about it have already written an extension
> in C.
I agree with the goal.
> Now, I can see this mechanism evolving in several directions. Either we
> remove it entirely, or we add a list ok known custom_variable_classes
> and SINVAL support for it so that as soon as the setting changes, all
> concurrent backends know about it, and so that you have a catalog cache
> to walk through rather than a real catalog to seqscan and backend init.
It'd certainly be better to jigger this so that we do syscache lookups
for each CVC that is actually needed rather than seq-scanning the
whole catalog. Even that is going to be slower than the present
method, but at least the overhead is proportional to the number of
CVCs you're actually using - and in particular, it's zero if no CVCs
are in use, which must be regarded as one of the common cases.
But I'm not sure that by itself is enough to save this proposal.
Right now, custom_variable_classes is a server-wide setting. But what
happens if you install an extension into database A and then set a
related configuration parameter in postgresql.conf? When connecting
to database A, things are OK. But as soon as someone tries to connect
to database B, the wheels come off. Either the connection fails
(which seems pretty undesirable) or it works but we don't process
those GUCs (which is outright broken if the extension requires that
every backend see the same value - think for example of a
PGC_POSTMASTER option controlling shared memory allocation).
My gut feeling at the moment is that, given enough time and thought,
there may well be a way to work through all of this and come up with a
design that works. But we're pretty tight on time right now, and even
if we had a perfect design today, I think I'd still argue for putting
it in a separate patch. I think that the value of extensions is first
and foremost that they can simplify installing, removing, dumping, and
restoring extensions. I'd rather see us nail that, and then worry
about custom_variable_classes as a separate issue, likely for 9.2 or
beyond. Otherwise, I am afraid (as I am for all the big patches we
have in the works at this point) that we may end up with nothing.
That would be a real shame.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company