Re: bootstrap pg_shseclabel in relcache initialization - Mailing list pgsql-hackers

From Tom Lane
Subject Re: bootstrap pg_shseclabel in relcache initialization
Date
Msg-id 30864.1447259497@sss.pgh.pa.us
Whole thread Raw
In response to Re: bootstrap pg_shseclabel in relcache initialization  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: bootstrap pg_shseclabel in relcache initialization  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
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 :-(.  As noted in elog.c, it doesn't seem
> like a terribly good idea to send WARNING messages while the client
> is still in authentication mode; we can't be very sure that clients
> will react desirably.  So we can't fix it by mucking with that.

> One answer is to promote the case to an ERROR.  We could (probably) keep
> a bad initfile from becoming a permanent lockout condition by unlinking
> the initfile before reporting ERROR, but this way still seems like a
> reliability hazard that could be worse than the original problem.

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' ability to recover from corner cases
we might not've foreseen.

Of course, if you run an assert-enabled build in production, you might
possibly lose.  But that's never been recommended practice.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Some questions about the array.
Next
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql: Translation updates