Re: Missing checks when malloc returns NULL...

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Missing checks when malloc returns NULL...
Date: 2016-08-30 13:35:32
Message-ID: 25632.1472564132@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> On Tue, Aug 30, 2016 at 10:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I think what we ought to do is make ShmemAlloc act like palloc
>> (ie throw error not return NULL), and remove the duplicated error
>> checks.

> The only reason why I did not propose that for ShmemAlloc is because
> of extensions potentially using this routine and having some special
> handling when it returns NULL. And changing it to behave like palloc
> would break such extensions.

The evidence from the callers in core suggests that this change
would be much more likely to fix extensions than break them,
ie it's more likely that they are missing error checks than that
they have something useful to do if the alloc fails.

An extension that actually does need that could do something like

#if CATALOG_VERSION_NO < whatever-v10-is
#define ShmemAllocNoError(x) ShmemAlloc(x)
#endif

...

ptr = ShmemAllocNoError(size);
if (ptr == NULL) // same as before from here on

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-08-30 13:42:45 Re: Missing checks when malloc returns NULL...
Previous Message Michael Paquier 2016-08-30 13:35:02 Re: standalone backend PANICs during recovery