On Tue, Jan 13, 2015 at 10:10 AM, Tom Lane <t...@sss.pgh.pa.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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
