Re: The return value of allocate_recordbuf() - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: The return value of allocate_recordbuf()
Date
Msg-id 54A137A8.6090108@vmware.com
Whole thread Raw
In response to The return value of allocate_recordbuf()  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: The return value of allocate_recordbuf()  (Robert Haas <robertmhaas@gmail.com>)
Re: The return value of allocate_recordbuf()  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 12/26/2014 09:31 AM, Fujii Masao wrote:
> Hi,
>
> While reviewing FPW compression patch, I found that allocate_recordbuf()
> always returns TRUE though its source code comment says that FALSE is
> returned if out of memory. Its return value is checked in two places, but
> which is clearly useless.
>
> allocate_recordbuf() was introduced by 7fcbf6a, and then changed by
> 2c03216 so that palloc() is used instead of malloc and FALSE is never returned
> even if out of memory. So this seems an oversight of 2c03216. Maybe
> we should change it so that it checks whether we can enlarge the memory
> with the requested size before actually allocating the memory?

Hmm. There is no way to check beforehand if a palloc() will fail because 
of OOM. We could check for MaxAllocSize, though.

Actually, before 2c03216, when we used malloc() here, the maximum record 
size was 4GB. Now it's only 1GB, because of MaxAllocSize. Are we OK with 
that, or should we use palloc_huge?

- Heikki




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps
Next
From: Abhijit Menon-Sen
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL