Re: upgrade failure from 9.5 to head

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

In response to

Responses

Browse pgsql-hackers by date

  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