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()
|
Список | 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 по дате отправления: