From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Lowering the ever-growing heap->pd_lower |
Date: | 2022-02-16 20:14:16 |
Message-ID: | CAEze2Wg2PdCGoZJsj_dsOEoqMCwKOfb4_Q71wxB0ivoD8pyZzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 16 Feb 2022 at 20:54, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Tue, Feb 15, 2022 at 10:48 AM Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)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).
Good catch, it is not. Attached a version that re-establishes maxoff
after each prune operation.
-Matthias
Attachment | Content-Type | Size |
---|---|---|
v8-0001-Improve-application-of-line-pointer-array-truncat.patch | application/octet-stream | 5.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2022-02-16 20:17:10 | Re: check-world has suddenly started spewing stuff on stderr |
Previous Message | Robert Haas | 2022-02-16 20:11:56 | Re: do only critical work during single-user vacuum? |