| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:29:03 |
| Message-ID: | CAB7nPqRDbjezFe_AeA8zYVqx20yZwW9n3Aj93KO5485D2G8BHA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. For the one caller that that would be bad for, we could
> invent something like ShmemAllocNoError, or ShmemAllocExtended with
> a no_error flag, or whatever other new API suits your fancy. But
> as-is, it's just inviting more errors-of-omission like the large
> number that already exist. I think people are conditioned by palloc
> to expect such functions to throw error.
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.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aleksander Alekseev | 2016-08-30 13:30:49 | Re: Missing checks when malloc returns NULL... |
| Previous Message | Tom Lane | 2016-08-30 13:24:33 | Re: standalone backend PANICs during recovery |