Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

> Pushed, with one cosmetic change (update comment on formrdesc). I also > bumped the catversion, but didn't verify whether this is critical. Excellent! Thanks! -Adam -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

> So this looks like a bugfix that we should backpatch, but on closer > inspection it turns out that we need the rowtype OID to be fixed, which > it isn't unless this: > >> -CATALOG(pg_shseclabel,3592) BKI_SHARED_RELATION BKI_WITHOUT_OIDS >> +CATALOG(pg_shseclabel,3592) BKI_SHARED_RELATION

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Alvaro Herrera wrote: > I'm gonna push this to master only, which means you won't be able to > rely on pg_shseclabel until 9.6. Pushed, with one cosmetic change (update comment on formrdesc). I also bumped the catversion, but didn't verify whether this is critical. -- Álvaro Herrera

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Adam Brightwell wrote: > While working on an auth hook, I found that I was unable to access the > pg_shseclabel system table while processing the hook. [ ... ] > Given that the shared relations currently exposed can also have > security labels that can be used for auth purposes, I believe it

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

I wrote: > When I checked the behavior of 5d1ff6bd559ea8df, I must have only > tried it for unshared catalogs. Those are set up by > RelationCacheInitializePhase3, which is post-authentication, so the > message comes out and causes regression test failures as expected. > This is kind of annoying

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

On 11/11/2015 11:31 AM, Tom Lane wrote: > After sleeping on it, the best compromise I can think of is to add an > "Assert(false)" after the WARNING report for the shared-catalogs case. > This will make the failure un-missable in any development build, while > not breaking production builds'

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

> In commit 5d1ff6bd559ea8df I'd expected that the > WARNINGs would certainly show up in regression test output, and I thought > I'd verified that that was the case --- did that not happen for you? I just doubled checked with both 'check' and 'check-world' and neither seemed to have an issue with

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

On Tue, Nov 10, 2015 at 9:18 AM, Adam Brightwell wrote: >> I'm with Alvaro: the most interesting question here is why that mistake >> did not blow up on you immediately. I thought we had enough safeguards >> in place to catch this type of error. > > Ok, I'll

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Adam Brightwell writes: > On Tue, Nov 10, 2015 at 9:18 AM, Adam Brightwell > wrote: >>> I'm with Alvaro: the most interesting question here is why that mistake >>> did not blow up on you immediately. I thought we had enough

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Adam Brightwell writes: >> In commit 5d1ff6bd559ea8df I'd expected that the >> WARNINGs would certainly show up in regression test output, and I thought >> I'd verified that that was the case --- did that not happen for you? > I just doubled checked with both

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

> -Original Message- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Joe Conway > Sent: Tuesday, November 10, 2015 3:08 AM > To: Craig Ringer; Adam Brightwell > Cc: PostgreSQL Hackers > Subject: Re: [HACKERS] bo

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

> I'm with Alvaro: the most interesting question here is why that mistake > did not blow up on you immediately. I thought we had enough safeguards > in place to catch this type of error. Ok, I'll explore that a bit further as I was able to build and use with my hook without any issue. :-/ -Adam

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

>> +1 for adding to the next commitfest. >> > Me also. Done. -Adam -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Adam Brightwell writes: >>> Need to bump this #define? If you didn't get the error that this is >>> supposed to throw, perhaps there's a bug somewhere worth investigating. > Whoops! It must be getting late... updated patch attached. I'm with Alvaro: the most

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

>> @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void) >> AuthIdRelationId); >> load_critical_index(AuthMemMemRoleIndexId, >> AuthMemRelationId); >> +

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

On 2015-11-09 23:38:57 -0500, Adam Brightwell wrote: > >> @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void) > >> AuthIdRelationId); > >> load_critical_index(AuthMemMemRoleIndexId, > >>

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

>> >> #define NUM_CRITICAL_SHARED_INDEXES 5/* fix if you change list >> >> above */ >> >> >> > >> > Need to bump this #define? If you didn't get the error that this is >> > supposed to throw, perhaps there's a bug somewhere worth investigating. >> >> Hmm... I thought that I had, are you

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

Adam Brightwell wrote: > @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void) > AuthIdRelationId); > load_critical_index(AuthMemMemRoleIndexId, > AuthMemRelationId); > +

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

On 11/08/2015 11:17 PM, Craig Ringer wrote: > On 9 November 2015 at 12:40, Adam Brightwell > wrote: >> Hi All, >> >> While working on an auth hook, I found that I was unable to access the >> pg_shseclabel system table while processing the hook. I discovered >>

Re: [HACKERS] bootstrap pg_shseclabel in relcache initialization

On 9 November 2015 at 12:40, Adam Brightwell wrote: > Hi All, > > While working on an auth hook, I found that I was unable to access the > pg_shseclabel system table while processing the hook. I discovered > that the only tables that were bootstrapped and made

[HACKERS] bootstrap pg_shseclabel in relcache initialization

Hi All, While working on an auth hook, I found that I was unable to access the pg_shseclabel system table while processing the hook. I discovered that the only tables that were bootstrapped and made available at this stage of the the auth process were pg_database, pg_authid and pg_auth_members.