On 07/29/2015 11:28 AM, Tom Lane wrote:
Stephen Frost <sfr...@snowman.net> writes:
* Tom Lane (t...@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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
