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
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 |