On August 20, 2015 at 7:21:10 AM, Tom Lane (tgl@sss.pgh.pa.us(mailto:tgl@sss.pgh.pa.us)) wrote:
> I'm not sure that the situation you describe can be expected to work
> reliably; the problems are far wider than just GUC variables. If two
> different .so's are exposing broadly the same set of C function names,
> how can we be sure which one will get called by the dynamic linker?
> Isn't it likely that we'd end up continuing to call some functions
> out of the old .so, probably leading to disaster?
Well, when you put it that way it sounds pretty scary :)
For whatever it’s worth, we’ve had versioned .so’s for a very long time, and every time an upgrade happens there is a
periodduring which a backend will have two versions loaded simultaneously. But we only noticed recently when we got the
GUCcollision (our first GUC was only introduced in PostGIS 2.1). Perhaps because after upgrading most people
disconnect,and then the next time they connect they only get the new library henceforth. In some cases (start a fresh
backendand then do the upgrade immediately) it’s even possible to do an upgrade without triggering the double-load
situation.
> I don't necessarily object to providing some solution for GUCs, but
> I think first we need to question whether that isn't just the tip of
> a large iceberg.
There’s no doubt that the GUC issue is just a symptom of a potentially awful larger disease, but so far it’s the only
symptomwe’ve observed. Maybe because only a small % of functionality ever changes in a given release, combined with the
relativelyshort lifespan of the double-loaded condition, and the fact the problem goes away immediately on re-connect,
anyproblems have always just been ignored.
P.