On Apr 8, 2016 1:13 AM, "Tom Lane" wrote:
>
> Magnus Hagander writes:
> > On Apr 7, 2016 9:14 PM, "Christian Ullrich"
wrote:
> >> Magnus, do you intend to commit the patch before the feature freeze?
>
> > It's on my list of things to work on this weekend, yeah.
>
> But the stated feature freeze
Magnus Hagander writes:
> On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote:
>> Magnus, do you intend to commit the patch before the feature freeze?
> It's on my list of things to work on this weekend, yeah.
But the stated feature freeze deadline is tomorrow (Friday), not the
weekend or later.
Alvaro Herrera writes:
> Tom Lane wrote:
>> 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 friend
Tom Lane wrote:
> Alvaro Herrera 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
Alvaro Herrera 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) d
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 STATU
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
* From: Alvaro Herrera [mailto:alvhe...@2ndquadrant.com]
> Christian Ullrich wrote:
> > * Christian Ullrich wrote:
> >
> > >* From: Magnus Hagander [mailto:mag...@hagander.net]
>
> > >>Code uses a mix of malloc() and palloc() (through sprintf). Is there
> > >>a reason for that?
> > >
> > >I wasn
Christian Ullrich wrote:
> * Christian Ullrich wrote:
>
> >* From: Magnus Hagander [mailto:mag...@hagander.net]
> >>Code uses a mix of malloc() and palloc() (through sprintf). Is there a
> >>reason for that?
> >
> >I wasn't sure which to prefer, so I looked around in auth.c, and other than
> >RAD
