Re: The return value of allocate_recordbuf()

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The return value of allocate_recordbuf()
Date: 2014-12-29 11:14:48
Message-ID: 54A137A8.6090108@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Abhijit Menon-Sen 2014-12-29 12:04:38 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Heikki Linnakangas 2014-12-29 10:50:23 Re: [COMMITTERS] pgsql: Keep track of transaction commit timestamps