On 04/04/2014 11:41 AM, Andres Freund wrote:
On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:@@ -484,10 +483,11 @@ PageRepairFragmentation(Page page) ((PageHeader) page)->pd_upper = pd_special; } else - { /* nstorage != 0 */ + { /* Need to compact the page the hard way */ - itemidbase = (itemIdSort) palloc(sizeof(itemIdSortData) * nstorage); - itemidptr = itemidbase; + itemIdSortData itemidbase[MaxHeapTuplesPerPage]; + itemIdSort itemidptr = itemidbase; +That's a fair bit of stack, and it can be called somewhat deep on the stack via heap_page_prune_opt(). I wonder if we ought to add a check_stack_depth() somewhere.
Hmm, on my 64-bit laptop, that array is 24*291=6984 bytes with 8k block size. That's fairly large, but not unheard of; there are a few places where we allocate a BLCKSZ-sized buffer from stack.
We could easily reduce the stack consumption here by changing itemIdSort to use 16-bit ints; all the lengths and offsets that PageRepairFragmentation deals with fit in 16-bits.
But overall I wouldn't worry about it. check_stack_depth() leaves a fair amount of headroom: STACK_DEPTH_SLOP is 512kB. As long as we don't recurse, that's plenty.
- Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
