* 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'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 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
What *could* happen, anyway? Can ereport(ERROR) in a backend make the
postmaster panic badly enough to force a shared memory reset?
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: