From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(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 08:41:08 |
Message-ID: | 20140404084108.GJ17307@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2014-04-04 10:48:32 +0300, Heikki Linnakangas wrote:
> But if we give the checkpointer process a free pass, running the regression
> tests with an assertion in AllocSetAlloc catches five genuine bugs:
>
> 1. _bt_newroot
> 2. XLogFileInit
> 3. spgPageIndexMultiDelete
> 4. PageRepairFragmentation
> 5. PageIndexMultiDelete
Some of those, like PageRepairFragmentation, are somewhat bad...
> @@ -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.
Thanks,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2014-04-04 09:50:25 | Re: WAL format and API changes (9.5) |
Previous Message | Heikki Linnakangas | 2014-04-04 07:48:32 | Re: WAL format and API changes (9.5) |