* 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 
noticed yet.

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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to