Re: upgrade failure from 9.5 to head - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: upgrade failure from 9.5 to head
Date
Msg-id 20150902013925.GI27332@momjian.us
Whole thread Raw
In response to Re: upgrade failure from 9.5 to head  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jul 29, 2015 at 11:01:40AM -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2015-07-29 10:38:19 -0400, Tom Lane wrote:
> >> Now as far as dummy_seclabel is concerned, the easy answer is "we don't
> >> care".  But on reflection, doesn't this mean that the entire
> >> implementation of SECURITY LABEL is broken?  At least to the extent that
> >> it can't work during pg_upgrade unless the user takes manual action to
> >> configure the relevant providers' .so libraries into the new installation
> >> *before* he runs pg_upgrade.  That doesn't say "production ready" to me.
> 
> > Hm, I don't think that particular issue is that bad. We decided labels
> > are only going to work if they're in shared_preload_libararies, and they
> > really only do if that's the case.
> 
> In that case, where in the documentation of the pg_upgrade process does
> it say "you must configure the new installation with all security label
> providers installed in shared_preload_libraries after initdb'ing the
> new installation and before running pg_upgrade"?  And how can you meet
> that requirement if you are using a canned script that does both those
> steps for you?  (Red Hat certainly ships such a script in their packaging,
> and I rather imagine that the Debian-style packages do too.)

The pg_upgrade docs have:
   <title>Install custom shared object files</title>
   <para>    Install any custom shared object files (or DLLs) used by the old cluster    into the new cluster, e.g.
<filename>pgcrypto.so</filename>,   whether they are from <filename>contrib</filename>    or some other source. Do not
installthe schema definitions, e.g.    <filename>pgcrypto.sql</>, because these will be upgraded from the old cluster.
 Also, any custom full text search files (dictionary, synonym,    thesaurus, stop words) must also be copied to the new
cluster.  </para>  </step>
 

Is that sufficient?  I think the thing that is missing is the need to
modify postgresql.conf, but you had to do that for the original setup
too.  Odds are they get an error, look at the message, figure out they
need shared_preload_libraries, and re-test it.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: synchronous_commit = apply
Next
From: Michael Paquier
Date:
Subject: Re: Fwd: Core dump with nested CREATE TEMP TABLE