From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: upgrade failure from 9.5 to head |
Date: | 2015-07-29 15:28:50 |
Message-ID: | 30178.1438183730@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2015-07-29 15:46:01 | Re: more RLS oversights |
Previous Message | Stephen Frost | 2015-07-29 15:17:56 | Re: upgrade failure from 9.5 to head |