Re: Upgrading Extension, version numbers (was: Extensions, patch v16)

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