On Sat, Aug 30, 2014 at 2:04 PM, Andres Freund <and...@2ndquadrant.com> wrote: > If the sort buffer is allocated when the checkpointer is started, not > everytime we sort, as you've done in your version of the patch I think > that risk is pretty manageable. If we really want to be sure nothing is > happening at runtime, even if the checkpointer was restarted, we can put > the sort array in shared memory.
I don't think that allocating the array at checkpointer start time helps. If it works, then you're strictly worse off than if you allocate it at every checkpoint, because you're holding onto the memory all the time instead of only when it's being used. And if it fails, what then? Sure, you can have that copy of the checkpointer process exit, but that does nothing good. The postmaster will keep on restarting it and it will keep on dying for lack of memory, and no checkpoints will complete. Oops. So it seems to me that the possibly-sensible approaches are: 1. Allocate an array when we need to sort, and if the allocation fails, have some kind of fallback strategy, like logging a WARNING an writing the buffers out without sorting them. If it succeeds, do the checkpoint and then free the memory until we need it again. 2. Putting the array in shared_memory, so that once the server is started, we can be sure the memory is allocated and the sort will work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
