Re: Upgrading Extension, version numbers (was: Extensions, patch v16) - Mailing list 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@.lo set extension lo;
>    alter function @extschema@.lo_oid(lo) set extension lo;
>    alter function @extschema@.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