From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Safe memory allocation functions |
Date: | 2015-01-15 02:42:16 |
Message-ID: | 20150115024216.GM1663@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas wrote:
> On Tue, Jan 13, 2015 at 10:10 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > However, there is a larger practical problem with this whole concept,
> > which is that experience should teach us to be very wary of the assumption
> > that asking for memory the system can't give us will just lead to nice
> > neat malloc-returns-NULL behavior. Any small perusal of the mailing list
> > archives will remind you that very often the end result will be SIGSEGV,
> > OOM kills, unrecoverable trap-on-write when the kernel realizes it can't
> > honor a copy-on-write promise, yadda yadda. Agreed that it's arguable
> > that these only occur in misconfigured systems ... but misconfiguration
> > appears to be the default in a depressingly large fraction of systems.
> > (This is another reason for "_safe" not being the mot juste :-()
>
> I don't really buy this. It's pretty incredible to think that after a
> malloc() failure there is absolutely no hope of carrying on sanely.
> If that were true, we wouldn't be able to ereport() out-of-memory
> errors at any severity less than FATAL, but of course it doesn't work
> that way. Moreover, AllocSetAlloc() contains malloc() and, if that
> fails, calls malloc() again with a smaller value, without even
> throwing an error.
I understood Tom's point differently: instead of malloc() failing,
malloc() will return a supposedly usable pointer, but later usage of it
will lead to a crash of some sort. We know this does happen in reality,
because people do report it; but we also know how to fix it. And for
systems that have been correctly set up, the new behavior (using some
plan B for when malloc actually fails instead of spuriously succeeding
only to cause a later crash) will be much more convenient.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-01-15 02:44:11 | Re: hung backends stuck in spinlock heavy endless loop |
Previous Message | Michael Paquier | 2015-01-15 02:27:01 | Re: Out-of-bounds write and incorrect detection of trigger file in pg_standby |