On Wed, Jul 29, 2015 at 11:01:40AM -0400, Tom Lane wrote:
> Andres Freund <and...@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 install the 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  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to