Andres Freund <and...@2ndquadrant.com> writes: > On 2014-06-14 16:57:33 -0400, Tom Lane wrote: >> I'm beginning to think we're going to have to give up on that >> no-pallocs-in-critical-sections Assert. It was useful to catch >> unnecessarily-dangerous allocations in mainline cases, but getting rid >> of every last corner-case palloc is looking to be, if not impossible, >> at least a lot more trouble than it is worth.
> I think we at least need to remove it from 9.4. We shouldn't release > with an assertion that still regularly triggers in more or less > 'harmless' situations. Yeah, it's certainly not looking like it's a production-ready check, even bearing in mind that we recommend against enabling asserts in production. > I think it might be worthwile to keep it in master to help maintain the > rule against allocations in critical sections. And perhaps as a reminder > that e.g. the checkpointer is doing bad things... I've looked at the checkpointer issue, and I don't actually think it's particularly unsafe there, mainly because the checkpointer's memory usage is pretty well bounded. I don't like the hacky solution of excepting *all* pallocs in the checkpointer process, though. I wonder whether we could set up some sort of marking of specific pallocs as being considered OK for the purposes of this assert. Another thought: the checkpointer has a guaranteed maximum on the size of the palloc in AbsorbFsyncRequests, viz CheckpointerShmem->max_requests ... maybe we should just make it prealloc that much space and be done. However, I wouldn't bother unless we are committed to keeping the Assert. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers