* 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? -- Christian -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers