| 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-02-09 12:02:35 |
| Message-ID: | CAB7nPqQFRPEGn18vycgn6kPgtxda40_9MKqwBnSfNS7UmCeREQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Feb 9, 2015 at 7:58 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> MemoryContextAllocExtended() was added, so isn't it time to replace palloc()
> with MemoryContextAllocExtended(CurrentMemoryContext, MCXT_ALLOC_NO_OOM)
> in allocate_recordbuf()?
Yeah, let's move on here, but not with this patch I am afraid as this
breaks any client utility using xlogreader.c in frontend, like
pg_xlogdump or pg_rewind because MemoryContextAllocExtended is not
available in frontend, only in backend. We are going to need something
like palloc_noerror, defined on both backend (mcxt.c) and frontend
(fe_memutils.c) side.
Btw, the huge flag should be used as well as palloc only allows
allocation up to 1GB, and this is incompatible with ~9.4 where malloc
is used.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hakan Kocaman | 2015-02-09 12:13:00 | Re: For cursors, there is FETCH and MOVE, why no TELL? |
| Previous Message | Fujii Masao | 2015-02-09 11:29:38 | Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code |