Re: WAL format and API changes (9.5)
От | Andres Freund |
---|---|
Тема | Re: WAL format and API changes (9.5) |
Дата | |
Msg-id | 20140404084108.GJ17307@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: WAL format and API changes (9.5) (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Ответы |
Re: WAL format and API changes (9.5)
|
Список | 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
В списке pgsql-hackers по дате отправления: