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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers