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

Reply via email to