From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WAL format and API changes (9.5) |
Date: | 2014-04-04 09:50:25 |
Message-ID: | 533E8061.7080508@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-04-04 10:05:06 | Re: WAL format and API changes (9.5) |
Previous Message | Andres Freund | 2014-04-04 08:41:08 | Re: WAL format and API changes (9.5) |