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

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

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 (view raw or flat)
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


In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-01-03 19:11:23
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Previous:From: Robert HaasDate: 2011-01-03 19:01:36
Subject: Re: pg_dump --split patch

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