Tom Lane wrote: > Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > > So, it seems that ClientAuthentication() expects to raise ereport(FATAL) > > in case of authentication failures. But what's the code path that > > causes that to happen if a ereport(ERROR) happens in there? Because all > > that code is pretty careful to not do ereport(ERROR) directly and > > instead return STATUS_ERROR which makes ClientAuthentication do the > > FATAL report. If this doesn't matter, then isn't this whole code overly > > complicated for no reason? > > The reason why elog(ERROR) will become a FATAL is that no outer setjmp > has been executed yet, so elog.c will realize it has noplace to longjmp > to.
Ah, I was looking callers up-stack and found nothing. That should have cued me that that was happening :-) > Anyway, as things stand, elog(ERROR) will abort the session safely but > you won't necessarily get the kind of logging you want, so expected > auth-failure cases should try to go the STATUS_ERROR route. In other words, the use of palloc() and friends (psprintf in the patch) should be acceptable here. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers