Re: upgrade failure from 9.5 to head

On 07/29/2015 11:28 AM, Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Tom Lane (tgl@sss.pgh.pa.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
PROCESSINGTOC:   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
notset 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