Re: The return value of allocate_recordbuf()

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: The return value of allocate_recordbuf()
Дата
Msg-id CAHGQGwFzU+pnVduRtKTQPf3yrL57zp0sxz5D0M5WaBzOPHQMiA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: The return value of allocate_recordbuf()  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: The return value of allocate_recordbuf()  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Fri, Apr 3, 2015 at 2:30 PM, Michael Paquier
<michael.paquier@gmail.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Sawada Masahiko
Дата:
Сообщение: Re: Auditing extension for PostgreSQL (Take 2)
Следующее
От: Shigeru Hanada
Дата:
Сообщение: Re: Custom/Foreign-Join-APIs (Re: [v9.5] Custom Plan API)