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
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 |