On Wed, Jul 29, 2015 at 11:01:40AM -0400, Tom Lane wrote:
> Andres Freund 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
On 08/04/2015 02:09 PM, Tom Lane wrote:
Robert Haas writes:
On Tue, Aug 4, 2015 at 1:54 PM, Andres Freund wrote:
On 2015-08-04 13:52:54 -0400, Tom Lane wrote:
Not sure whether we should consider it a back-patchable bug fix or
something to do only in HEAD, though --- comments?
Tentatively I
Robert Haas writes:
> On Tue, Aug 4, 2015 at 1:54 PM, Andres Freund wrote:
>> On 2015-08-04 13:52:54 -0400, Tom Lane wrote:
>>> Not sure whether we should consider it a back-patchable bug fix or
>>> something to do only in HEAD, though --- comments?
>> Tentatively I'd say it's a bug and should b
On Tue, Aug 4, 2015 at 1:54 PM, Andres Freund wrote:
> On 2015-08-04 13:52:54 -0400, Tom Lane wrote:
>> Not sure whether we should consider it a back-patchable bug fix or
>> something to do only in HEAD, though --- comments?
>
> Tentatively I'd say it's a bug and should be back-patched.
Agreed.
On 2015-08-04 13:52:54 -0400, Tom Lane wrote:
> Not sure whether we should consider it a back-patchable bug fix or
> something to do only in HEAD, though --- comments?
Tentatively I'd say it's a bug and should be back-patched.
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Robert Haas writes:
> On Sun, Aug 2, 2015 at 8:20 PM, Stephen Frost wrote:
>> +1.
>>
>> I was doing testing the other day and ran into the "pg_dump doesn't
>> support shell types" issue and it was annoyingly confusing.
> Is anyone working on this? Should it be added to the open items list?
I
On Sun, Aug 2, 2015 at 8:20 PM, Stephen Frost wrote:
> +1.
>
> I was doing testing the other day and ran into the "pg_dump doesn't
> support shell types" issue and it was annoyingly confusing.
Is anyone working on this? Should it be added to the open items list?
--
Robert Haas
EnterpriseDB: ht
* Andres Freund (and...@anarazel.de) wrote:
> On 2015-08-01 19:13:05 -0400, Noah Misch wrote:
> > On Wed, Jul 29, 2015 at 04:42:55PM -0400, Andrew Dunstan wrote:
> > > The next hump is this, in restoring contrib_regression_test_ddl_parse:
> > >
> > >pg_restore: creating FUNCTION "public"."text
On 2015-08-02 19:06:49 -0400, Andrew Dunstan wrote:
> I'm fine with fixing it, but what's the actual use case for a long lived
> shell type?
The use-case imo is that we shouldn't just break if somebody did
something stupid or was busy creating a new type while a scheduled
backup ran.
Andres
--
On 08/02/2015 04:00 PM, Tom Lane wrote:
Andres Freund writes:
On 2015-08-01 19:13:05 -0400, Noah Misch wrote:
That's a bug. The test_ddl_deparse suite leaves a shell type, which
pg_upgrade fails to reproduce. Whether to have pg_upgrade support that or
just error out cleanly is another quest
Andres Freund writes:
> On 2015-08-01 19:13:05 -0400, Noah Misch wrote:
>> That's a bug. The test_ddl_deparse suite leaves a shell type, which
>> pg_upgrade fails to reproduce. Whether to have pg_upgrade support that or
>> just error out cleanly is another question.
> There seems little justifi
On 2015-08-01 19:13:05 -0400, Noah Misch wrote:
> On Wed, Jul 29, 2015 at 04:42:55PM -0400, Andrew Dunstan wrote:
> > The next hump is this, in restoring contrib_regression_test_ddl_parse:
> >
> >pg_restore: creating FUNCTION "public"."text_w_default_in("cstring")"
> >pg_restore: [archiver
On 08/01/2015 07:13 PM, Noah Misch wrote:
On Wed, Jul 29, 2015 at 04:42:55PM -0400, Andrew Dunstan wrote:
The next hump is this, in restoring contrib_regression_test_ddl_parse:
pg_restore: creating FUNCTION "public"."text_w_default_in("cstring")"
pg_restore: [archiver (db)] Error while
On Wed, Jul 29, 2015 at 04:42:55PM -0400, Andrew Dunstan wrote:
> The next hump is this, in restoring contrib_regression_test_ddl_parse:
>
>pg_restore: creating FUNCTION "public"."text_w_default_in("cstring")"
>pg_restore: [archiver (db)] Error while PROCESSING TOC:
>pg_restore: [archi
On 07/29/2015 11:28 AM, Tom Lane wrote:
Stephen Frost writes:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Really? What aspect of postgis requires mucking with
shared_preload_libraries?
Having to have the libraries in place is what I was getting at, which is
what Andres was also talking about, if
On Wed, Jul 29, 2015 at 11:28 AM, Tom Lane wrote:
> It's possible that the problem here is not so much reliance on
> shared_preload_libraries as it is that there's no provision in
> pg_upgrade for dealing with the need to set it. But one way or
> the other, this is a usability fail.
Andres prett
Stephen Frost writes:
> More generally, I completely agree that this is something which we can
> improve upon. It doesn't seem like a release blocker or something which
> we need to fix in the back branches though.
No, it's not a release blocker; it's been like this since we invented
security la
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Having to also deal with shared_preload_libraries for some cases doesn't
> > strike me as a huge issue.
>
> I think it is, especially if what we're offering as a workaround is "write
> a custom script and make sure that your pg_up
Tom Lane wrote:
> Andres Freund writes:
> > 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.
I set it up that way
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Really? What aspect of postgis requires mucking with
>> shared_preload_libraries?
> Having to have the libraries in place is what I was getting at, which is
> what Andres was also talking about, if I understood correctly.
Right,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Andres Freund (and...@anarazel.de) wrote:
> >> 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 onl
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund 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 LABE
Stephen Frost writes:
> * Andres Freund (and...@anarazel.de) wrote:
>> 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 .
Andres Freund 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 w
* Andres Freund (and...@anarazel.de) wrote:
> 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
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
Andres Freund 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 beca
Hi,
On 2015-07-29 10:16:10 -0400, Andrew Dunstan wrote:
>
> My cross-version upgrade testing tool just threw up this failure, upgrading
> from 9.5 to head:
>
>CREATE ROLE "dummy_seclabel_user1";
>CREATE ROLE
>ALTER ROLE "dummy_seclabel_user1" WITH NOSUPERUSER INHERIT
>CREATEROLE
Andrew Dunstan writes:
> My cross-version upgrade testing tool just threw up this failure,
> upgrading from 9.5 to head:
> CREATE ROLE "dummy_seclabel_user1";
> CREATE ROLE
> ALTER ROLE "dummy_seclabel_user1" WITH NOSUPERUSER INHERIT
> CREATEROLE NOCREATEDB LOGIN NOREPLICATION NO
29 matches
Mail list logo
