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