"David E. Wheeler" <da...@kineticode.com> writes: > I thought we were going to try to avoid having entries for upgrades in > the control file.
Not what I have understood. http://archives.postgresql.org/pgsql-hackers/2010-12/msg01014.php http://archives.postgresql.org/pgsql-hackers/2010-12/msg01045.php AS there was no answer, the meaning for me is that it was ok to proceed. On this list people agreeing often remain silent. >> Note that we always need to support the placeholder here, because of >> course following dependencies at this point isn't possible. > > I thought placeholders were going away, too. Did I lose track? Oh, dear, yes :) See the documentation for the relocatable parameter. We know handle two kinds of extensions, some of them you can't offer better than placeholders to allow users to define the schema where they will land. Also, at upgrade time, I don't see any other way to solve the problem. Do you? http://pgsql.tapoueh.org/extensions/doc/html/extend-extension.html >> At the time you tell PostgreSQL about the new extension, the shared >> object file has been in place for some time already, and the upgrade SQL >> script has not been ran yet. > > That sounds dangerous. Been doing that countless times. Yet to see a case where the new .so is not compatible at all with the previous .sql and the author don't give you any warning about the situation. In theory that's possible, in practice we value upgrades high enough around here. Other than that, I don't have another idea to make it work reliably. I'm still reading, though. Meanwhile I've done what seems like a good compromise and to follow practical use cases. >> What I hope extension authors will do is document whether any upgrade >> requires a restart or will otherwise be responsible for instability in >> the server for backend started with the newer .so before the upgrade >> script has been run. So that users/DBA will know whether the upgrade >> calls for a maintenance window. > > But if a new connection comes in, the .so will be loaded into the new child, > no? Very dangerous. Yeah. Before extension existed, it has always been working like that, our users already depend on such a behavior, nothing new here. I just don't see how extension could solve that is all I'm saying. > The new .so should not be installed until the upgrade is been run. Nice statement. How do you make that happen? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
