From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(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-02 00:10:44 |
Message-ID: | 20150402001044.GD13005@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 12, 2015 at 04:02:52PM +0900, Michael Paquier wrote:
> Yes, why not using palloc_extended instead of palloc_noerror that has been
> clearly rejected in the other thread. Now, for palloc_extended we should copy
> the flags of MemoryContextAllocExtended to fe_memutils.h and have the same
> interface between frontend and backend (note that MCXT_ALLOC_HUGE has no real
> utility for frontends). Attached is a patch to achieve that, completed with a
> second patch for the problem related to this thread. Note that in the second
> patch I have added an ERROR in logical.c after calling XLogReaderAllocate, this
> was missing..
>
>
> > 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.
>
> I think that flag should be used only if it's needed, not just on the
> grounds that 9.4 has no such limit. In general, limiting allocations
> to 1GB has been good to us; for example, it prevents a corrupted TOAST
> length from causing a memory allocation large enough to crash the
> machine (yes, there are machines you can crash with a giant memory
> allocation!). We should bypass that limit only where it is clearly
> necessary.
>
>
> Fine for me to error out in this code path if we try more than 1GB of
> allocation.
Where are we on this?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-04-02 00:20:51 | Re: The return value of allocate_recordbuf() |
Previous Message | Petr Jelinek | 2015-04-01 23:38:09 | Re: TABLESAMPLE patch |