Re: Lowering the ever-growing heap->pd_lower
Matthias van de Meent <boekewurm+postgres@gmail.com>
From: Matthias van de Meent <boekewurm+postgres@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-02-16T20:14:16Z
Lists: pgsql-hackers
Attachments
- v8-0001-Improve-application-of-line-pointer-array-truncat.patch (application/octet-stream) patch v8-0001
On Wed, 16 Feb 2022 at 20:54, Peter Geoghegan <pg@bowt.ie> wrote: > > 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). Good catch, it is not. Attached a version that re-establishes maxoff after each prune operation. -Matthias
Commits
-
Truncate line pointer array during heap pruning.
- 10a8d138235b 15.0 landed
-
Truncate line pointer array during VACUUM.
- 3c3b8a4b2689 14.0 landed