Re: BUG #7661: pgstattuple from unpackaged fails on old installation

From: Craig Ringer <craig(at)2ndQuadrant(dot)com>
To: Stuart Bishop <stuart(at)stuartbishop(dot)net>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #7661: pgstattuple from unpackaged fails on old installation
Date: 2012-11-15 09:17:40
Message-ID: 50A4B334.9010209@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On 11/15/2012 03:32 PM, Stuart Bishop wrote:
>> That's a known issue with several of the extensions. You need to upgrade
>> the contrib module install to the current version, *then* wrap the
>> unpackaged contrib module into an extension with "FROM UNPACKAGED".
> Yeah, just thought I'd stick it in the... umm... bugtracker, as so far
> 'FROM unpackaged' has failed in 66% of up updates. Is the real
> solution is for the foo--unpackaged--1.0.sql script to recreate
> missing objects before adding them to the extension?
For simple extensions running the create script should do the job, yes.
It's not so clear cut for extensions that define data types, though.

If I recall correctly the general advice for those has been to:

- Create the new versions of extensions in the DB you're going to
restore to; then
- restore your database to that DB with the extensions pre-created in it.

I'm surprised not to find any documentation on coping with this issue in:

http://www.postgresql.org/docs/current/static/contrib.html
<http://www.postgresql.org/docs/9.2/static/contrib.html>
or
http://www.postgresql.org/docs/current/static/extend-extensions.html
<http://www.postgresql.org/docs/9.2/static/extend-extensions.html>

(though it's possible it's there and I missed it).

There used to be brief mention in contrib.html before the extensions
changes went in, saying:

"After a major-version upgrade of PostgreSQL, run the installation
script again, even though the module's objects might have been brought
forward from the old installation by dump and restore. This ensures that
any new functions will be available and any needed corrections will be
applied."

... but I'm not certain that advice is sufficient for all contrib modules.

Extensions were created because upgrading DBs that used contrib modules
was a painful mess.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit kapila 2012-11-15 13:59:12 Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Previous Message Stuart Bishop 2012-11-15 07:32:36 Re: BUG #7661: pgstattuple from unpackaged fails on old installation