Skip site navigation (1) Skip section navigation (2)

Re: Upgrading Extension, version numbers

From: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Upgrading Extension, version numbers
Date: 2011-01-03 19:46:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"David E. Wheeler" <david(at)kineticode(dot)com> writes:
> I thought we were going to try to avoid having entries for upgrades in
> the control file.

Not what I have understood.

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?

>> 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?

Dimitri Fontaine     PostgreSQL : Expertise, Formation et Support

In response to


pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2011-01-03 19:49:44
Subject: Re: Extension upgrade, patch v0: debug help needed
Previous:From: Joel JacobsonDate: 2011-01-03 19:46:02
Subject: Re: pg_dump --split patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group