Re: pg_upgrade libraries check

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-29 18:09:44
Message-ID: 20120529180944.GH20260@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 29, 2012 at 01:46:28PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > I assumed I could just have pg_upgrade create and drop the extension in
> > the new database to make sure it works. In the JSON backpatch case, the
> > extension file would just do nothing, as has already been suggested.
>
> It seems like checking for the control file being present should be
> sufficient. I don't think it's part of pg_upgrade's job description to
> test whether the new installation is broken. And we don't really want
> it cluttering the new installation with dead objects right off the bat
> (could cause OID issues or LSN issues, for instance).

True. I just wasn't sure the control file method was fool-proof enough.

> > In fact, can we identify right now if a function is used only by an
> > extension?
>
> ITYM is the function defined by an extension, and the answer to that is
> "look in pg_depend".

So is this something I should be exploring, or not worth it at this
time? It would allow changing the names of extension shared object
files, but right now I don't know anyone doing that, so I am not sure of
the value of the change.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-05-29 18:19:52 Re: Issues with MinGW W64
Previous Message Tom Lane 2012-05-29 17:46:28 Re: pg_upgrade libraries check