On 2015-07-29 10:38:19 -0400, Tom Lane wrote: > 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
Hm. That issue doesn't particularly concern me. Having all .so's available in the installation seems like a pretty basic requirement. Security labels are by far not the only things that'll fail without an extension's .so present, no? > (b) even if he did, there's nothing that would cause it to get loaded > during pg_upgrade's DDL restore run. Well, generally it's assumed that all security labels are loaded via shared_preload_libraries. I'm not super happy about that decision, but given the desire to be able to have labels on shared objects I can see the reasoning. > 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. I think if we think we should do something here we should add a check that label providers are loaded in s_p_l. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers