"David E. Wheeler" <david@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
