Re: upgrade failure from 9.5 to head

On 07/29/2015 11:28 AM, Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>>> Really? What aspect of postgis requires mucking with
>>> shared_preload_libraries?
>> Having to have the libraries in place is what I was getting at, which is
>> what Andres was also talking about, if I understood correctly.
> Right, I agree with that: you need to have installed all the software
> you're using, where "installed" means "the executable files are built
> and placed where they need to be in the filesystem".
>
>> Having to also deal with shared_preload_libraries for some cases doesn't
>> strike me as a huge issue.
> I think it is, especially if what we're offering as a workaround is "write
> a custom script and make sure that your pg_upgrade wrapper script has an
> option to call that halfway through". Rube Goldberg would be proud.
>
> It's possible that the problem here is not so much reliance on
> shared_preload_libraries as it is that there's no provision in
> pg_upgrade for dealing with the need to set it. But one way or
> the other, this is a usability fail.

FWIW, having the test driver add the shared_preload_libraries setting
got over this hump - the shared library is indeed present in my setup.

The next hump is this, in restoring contrib_regression_test_ddl_parse:

pg_restore: creating FUNCTION "public"."text_w_default_in("cstring")"
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 243; 1255 62534
FUNCTION text_w_default_in("cstring") buildfarm
pg_restore: [archiver (db)] could not execute query: ERROR: pg_type
OID value not set when in binary upgrade mode
Command was: CREATE FUNCTION "text_w_default_in"("cstring")
RETURNS "text_w_default"
LANGUAGE "internal" STABLE STRICT
AS $$texti...

Is this worth bothering about, or should I simply remove the database
before trying to upgrade?

cheers

andrew