From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | 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 (was: Extensions, patch v16) |
Date: | 2011-01-03 19:08:45 |
Message-ID: | C4579C00-BDE2-4B0D-8A6B-4B9B9FEDD530@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Dec 29, 2010, at 2:01 PM, Dimitri Fontaine wrote:
> # lo
> comment = 'managing Large Objects'
> version = '9.1devel'
> relocatable = true
> upgrade_from_null = 'null => lo.upgrade.sql'
>
> Here, any property that begins with 'upgrade_from_' is considered as an
> upgrade setup and the part after the prefix is not considered. The
> value is meant to have two parts separated by '=>', first is either null
> or a regexp matched against currently installed version number, second
> part is the upgrade script name to use at ALTER EXTENSION ... UPGRADE.
I thought we were going to try to avoid having entries for upgrades in the control file.
> We support 'null' version number to be able to "upgrade" from existing
> code which is not organized as an extension yet. The aim is to be able
> to:
>
> CREATE EMPTY EXTENSION lo; -- version is null here
> ALTER EXTENSION lo UPGRADE;
>
> And run a script containing lines that will look like this:
>
> alter domain @extschema(at)(dot)lo set extension lo;
> alter function @extschema(at)(dot)lo_oid(lo) set extension lo;
> alter function @extschema(at)(dot)lo_manage() set extension lo;
>
> 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?
> Well, the way I see things, it's already too late and there's nothing we
> can easily do to prevent that. What I mean is that the user will
> typically upgrade the OS-level package first, then apply the upgrade on
> the database(s).
>
> $ apt-get install postgresql-9.1-prefix
> $ psql -U postgres -c 'alter extension prefix upgrade' somedb
>
> 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.
> 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.
> I could see us trying to shoehorn such information into the control file
> too, but would ERRORing out on LOAD be any better than taking the
> compatibility chance? Knowing that the compatibility in most cases
> depends a lot on the actual call paths?
The new .so should not be installed until the upgrade is been run.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-03 19:11:23 | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |
Previous Message | Robert Haas | 2011-01-03 19:01:36 | Re: pg_dump --split patch |