| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(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 05:30:44 |
| Message-ID: | CAB7nPqQQUSJfxraG202friJMvxefwFkYKx6XqJz69fNK7jiLwQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Michael
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-palloc_extended-and-pg_malloc_extended-for-front.patch | text/x-diff | 5.2 KB |
| 0002-Rework-handling-of-OOM-when-allocating-record-buffer.patch | text/x-diff | 3.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sawada Masahiko | 2015-04-03 05:59:41 | Freeze avoidance of very large table. |
| Previous Message | Fujii Masao | 2015-04-03 03:56:31 | Re: The return value of allocate_recordbuf() |