* From: Alvaro Herrera [mailto:alvherre@2ndquadrant.com]
> Christian Ullrich wrote:
> > * Christian Ullrich wrote:
> >
> > >* From: Magnus Hagander [mailto:magnus@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 RADIUS, everything seems to use malloc() (although the
> > >sample size is not too great). Should I use palloc() instead?
> >
> > The single instance of malloc() has been replaced with palloc().
>
> I'm wary of palloc() in this code actually ... if the allocation fails,
> I'm not sure it's okay to use ereport(ERROR) which is what would happen
> with palloc. With the malloc code, you report the problem with
> elog(LOG) and then return STATUS_ERROR which lets the calling code
> handle the failure in a different way. I didn't actually review your
> new code, but I recall this from previous readings of auth code; so if
> you're going to use palloc(), you better audit what happens on OOM.
>
> For the same reason, using psprintf is probably not acceptable either.
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
nearlyevery error check in pg_SSPI_recvauth() ends up doing ereport(ERROR) already, directly or via pg_SSPI_error(). If
thiscould cause serious trouble, someone would have noticed yet.
What *could* happen, anyway? Can ereport(ERROR) in a backend make the postmaster panic badly enough to force a shared
memoryreset?
--
Christian