From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade libraries check |
Date: | 2012-05-27 16:08:14 |
Message-ID: | 20120527160814.GD20260@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, May 27, 2012 at 11:31:12AM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Sun, May 27, 2012 at 08:48:54AM -0400, Andrew Dunstan wrote:
> >> "things like CREATE LANGUAGE plperl" is a rather vague phrase. The
> >> PL case could be easily handled by adding this to the query:
> >> OR EXISTS (SELECT 1 FROM pg_catalog.pg_language WHERE lanplcallfoid
> >> = p.oid)
> >> Do you know of any other cases that this would miss?
>
> Well, laninline and lanvalidator for two ;-)
>
> > The problem is I don't know. I don't know in what places we reference
> > shared object files implicit but not explicitly, and I can't know what
> > future places we might do this.
>
> The "future changes" argument seems like a straw man to me. We're
> already in the business of adjusting pg_upgrade when we make significant
> catalog changes.
The bottom line is I just don't understand the rules of when a function
in the pg_catalog schema implicitly creates something that references a
shared object, and unless someone tells me, I am inclined to just have
pg_upgrade check everything and throw an error during 'check', rather
than throw an error during the upgrade. If someone did tell me, I would
be happy with modifying the pg_upgrade query to match.
Also, pg_upgrade rarely requires adjustments for major version changes,
and we want to keep it that way.
> > We are not writing a one-off pg_upgrade for JSON-backpatchers here.
>
> I tend to agree with that position, and particularly think that we
> should not allow the not-community-approved design of the existing
> JSON backport to drive changes to pg_upgrade. It would be better to
> ask first if there were a different way to construct that backport
> that would fit better with pg_upgrade.
Yep.
A command-line flag just seems too user-visible for this use-case, and
too error-pone. I barely understand what is going on, particularly with
plpython in "public" (which we don't fully even understand yet), so
adding a command-line flag seems like the wrong direction.
> Having said that, I've got to also say that I think we've fundamentally
> blown it with the current approach to upgrading extensions. Because we
> dump all the extension member objects, the extension contents have got
> to be restorable into a new database version as-is, and that throws away
> most of the flexibility that we were trying to buy with the extension
> mechanism. IMO we have *got* to get to a place where both pg_dump and
> pg_upgrade dump extensions just as "CREATE EXTENSION", and the sooner
> the better. Once we have that, this type of issue could be addressed by
> having different contents of the extension creation script for different
> major server versions --- or maybe even the same server version but
> different python library versions, to take something on-point for this
> discussion. For instance, Andrew's problem could be dealt with if the
> backport were distributed as an extension "json-backport", and then all
> that's needed in a new installation is an empty extension script of that
> name.
>
> More generally, this would mean that cross-version compatibility
> problems for extensions could generally be solved in the extension
> scripts, and not with kludges in pg_upgrade. As things stand, you can be
> sure that kludging pg_upgrade is going to be the only possible fix for
> a very wide variety of issues.
>
> I don't recall exactly what problems drove us to make pg_upgrade do
> what it does with extensions, but we need a different fix for them.
Uh, pg_upgrade doesn't do anything special with extensions, so it must
have been something people did in pg_dump.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-05-27 16:25:46 | Re: pg_upgrade libraries check |
Previous Message | Tom Lane | 2012-05-27 15:31:12 | Re: pg_upgrade libraries check |