On August 20, 2015 at 7:21:10 AM, Tom Lane (t...@sss.pgh.pa.us(mailto:t...@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 period during which a backend will have two versions loaded simultaneously. But we only noticed recently when we got the GUC collision (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 backend and 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 symptom we’ve observed. Maybe because only a small % of functionality ever changes in a given release, combined with the relatively short lifespan of the double-loaded condition, and the fact the problem goes away immediately on re-connect, any problems have always just been ignored. P. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
