From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: The return value of allocate_recordbuf() |
Date: | 2015-04-03 09:35:49 |
Message-ID: | CAHGQGwFzU+pnVduRtKTQPf3yrL57zp0sxz5D0M5WaBzOPHQMiA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 3, 2015 at 2:30 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> On Fri, Apr 3, 2015 at 12:56 PM, Fujii Masao wrote:
>> The first patch looks good to me basically. But I have one comment:
>> shouldn't we expose pg_malloc_extended as a global function like
>> we did pg_malloc? Some frontends might need to use it in the future.
>
> Yes, it makes sense as the other functions do it too. So I refactored
> the patch and defined a new static inline routine,
> pg_malloc_internal(), that all the other functions call to reduce the
> temperature in this code path that I suppose can become quite hot even
> for frontends. In the second patch I added as well what was needed for
> pg_rewind.
Thanks for updating the patches!
I pushed the first and a part of the second patch.
Regarding the second patch, you added the checks of the return value of
XLogReaderAllocate(). But it seems half-baked. XLogReaderAllocate() still
uses palloc(), but don't we need to replace it with palloc_extended(), too?
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Shigeru Hanada | 2015-04-03 10:32:08 | Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API) |
Previous Message | Sawada Masahiko | 2015-04-03 07:59:42 | Re: Auditing extension for PostgreSQL (Take 2) |