Re: Lowering the ever-growing heap->pd_lower
От | Peter Geoghegan |
---|---|
Тема | Re: Lowering the ever-growing heap->pd_lower |
Дата | |
Msg-id | CAH2-Wz=pLrgnqPta1tnN9kAoKYnSucue9XPpn3pKKnOibEzGcA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Lowering the ever-growing heap->pd_lower (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Ответы |
Re: Lowering the ever-growing heap->pd_lower
|
Список | pgsql-hackers |
On Tue, Feb 15, 2022 at 10:48 AM Matthias van de Meent <boekewurm+postgres@gmail.com> wrote: > Peter Geoghegan asked for good arguments for the two changes > implemented. Below are my arguments detailed, with adversarial loads > that show the problematic behaviour of the line pointer array that is > fixed with the patch. Why is it okay that lazy_scan_prune() still calls PageGetMaxOffsetNumber() once for the page, before it ever calls heap_page_prune()? Won't lazy_scan_prune() need to reestablish maxoff now, if only so that its scan-page-items loop doesn't get confused when it goes on to read "former line pointers"? This is certainly possible with the CLOBBER_FREED_MEMORY stuff in place (which will memset the truncated line pointer space with a 0x7F7F7F7F pattern). -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: