| From: | Aleksander Alekseev <a(dot)alekseev(at)postgrespro(dot)ru> |
|---|---|
| To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:30:49 |
| Message-ID: | 20160830133048.GA84635@e733 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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.
I suggest to keep ShmemAlloc as is for backward compatibility and
introduce a new procedure ShmemAllocSafe. Also we could add a scary
comment (and also a warning log message?) that ShmemAlloc is deprecated
and possibly will be removed in later releases.
--
Best regards,
Aleksander Alekseev
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2016-08-30 13:35:02 | Re: standalone backend PANICs during recovery |
| Previous Message | Michael Paquier | 2016-08-30 13:29:03 | Re: Missing checks when malloc returns NULL... |