Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used - Mailing list pgsql-bugs

From David Steele
Subject Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used
Date
Msg-id 56FA9AA4.9090005@pgmasters.net
Whole thread Raw
In response to Re: Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: [HACKERS] BUG #13854: SSPI authentication failure: wrong realm name used  (Magnus Hagander <magnus@hagander.net>)
List pgsql-bugs
On 3/24/16 5:22 PM, Alvaro Herrera wrote:
> Christian Ullrich wrote:
>
>> To be honest, I'm not sure what can and cannot be done in auth code. I
>> took inspiration from the existing SSPI code and nearly every error
>> check in pg_SSPI_recvauth() ends up doing ereport(ERROR) already,
>> directly or via pg_SSPI_error(). If this could cause serious trouble,
>> someone would have noticed yet.
>
> I think the problem is whether the report is sent to the client or not,
> but I may be confusing with something else (COMMERROR reports?).
>
>> What *could* happen, anyway? Can ereport(ERROR) in a backend make the
>> postmaster panic badly enough to force a shared memory reset?
>
> Probably not, since it's running in a backend already at that point, not
> in postmaster.

It seems like this patch should be set "ready for committer".  Can one 
of the reviewers do that if appropriate?

Thanks,
-- 
-David
david@pgmasters.net



pgsql-bugs by date:

Previous
From: mschuch@avaya.com
Date:
Subject: BUG #14050: "could not reserve shared memory region" in postgresql log
Next
From: Sasikishore.k@gmail.com
Date:
Subject: BUG #14052: outfile of pg_basebackup , are of different type. But after extractin the file size is same