Re: pg_upgrade libraries check - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgrade libraries check
Date
Msg-id 26348.1338143572@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgrade libraries check  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_upgrade libraries check
Re: pg_upgrade libraries check
Re: pg_upgrade libraries check
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> AIUI, for Tom's scheme to work pg_upgrade would need not to check 
> libraries that belonged to extension functions. Currently it simply 
> assumes that what is present in the old cluster is exactly what will be 
> needed in the new cluster. Tom's proposed scheme would completely 
> invalidate that assumption (which I would argue is already of doubtful 
> validity). Instead of explicitly trying to LOAD the libraries it would 
> have to rely on the "CREATE EXTENSION foo" failing, presumably at some 
> time before it would be too late to abort.

Well, the scheme I had in mind would require pg_upgrade to verify that
the new cluster contains an extension control file for each extension in
the old cluster (which is something it really oughta do anyway, if it
doesn't already).  After that, though, it ought not be looking at the
individual functions defined by an extension --- it is the extension's
business which libraries those are in.

The only reason for pg_upgrade to still look at probin at all would be
to cover C functions that weren't within extensions.  In the long run it
might be possible to consider those unsupported, or at least not common
enough to justify a safety check in pg_upgrade.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade libraries check
Next
From: Tom Lane
Date:
Subject: Re: pg_upgrade libraries check