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

From Tom Lane
Subject Re: upgrade failure from 9.5 to head
Date
Msg-id 28752.1438180699@sss.pgh.pa.us
Whole thread Raw
In response to Re: upgrade failure from 9.5 to head  (Andres Freund <andres@anarazel.de>)
Responses Re: upgrade failure from 9.5 to head  (Andres Freund <andres@anarazel.de>)
Re: upgrade failure from 9.5 to head  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2015-07-29 10:16:10 -0400, Andrew Dunstan wrote:
>> psql:pg_upgrade_dump_globals.sql:25: ERROR:  security label provider
>> "dummy" is not loaded

> Ick! So the dummy_seclabel test more or less only works by accident if I
> see that correctly. The .so is only loaded because the CREATE EXTENSION
> in the test triggers a CREATE FUNCTION dummy_seclabel_dummy() ... LANG
> C.

Well, there's a larger issue, which is that (a) Andrew's new installation
very likely doesn't have dummy_seclabel.so built/installed at all, and
(b) even if he did, there's nothing that would cause it to get loaded
during pg_upgrade's DDL restore run.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: upgrade failure from 9.5 to head
Next
From: Corey Huinker
Date:
Subject: Re: dblink: add polymorphic functions.