Adam Brightwell <adam.brightw...@crunchydata.com> 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 'check' and 'check-world' and neither
> seemed to have an issue with it. Though, I do see the warning show up
> in 'regress/log/postmaster.log'.
I poked around a bit and figured out what is wrong: for shared catalogs,
this message would be emitted during RelationCacheInitializePhase2(),
which is executed before we perform client authentication (as indeed
is rather your point here). That means ClientAuthInProgress is still
true, which means elog.c doesn't honor client_min_messages --- it
will only send ERROR or higher messages to the client. So the message
goes to the postmaster log, but not to the client.
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.
Another idea, which seems pretty grotty but might be workable, is
to save aside some state about the failure during
RelationCacheInitializePhase2 and then actually send the WARNING
during RelationCacheInitializePhase3. But that seems a little Rube
Goldberg-ish, and who's to say it couldn't break?
But I don't think I want to just do nothing. We already found out
how easy it is to not realize that we have a bug here, leading to
a serious backend-startup-performance issue.
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
