Re: upgrade failure from 9.5 to head

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: 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 14:38:19
Message-ID: 28752.1438180699@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2015-07-29 14:43:18 Re: dblink: add polymorphic functions.
Previous Message Tom Lane 2015-07-29 14:30:31 Re: upgrade failure from 9.5 to head