Message-ID: <acb89d4554f072f9dd30f2ae5b8b60092f3eb7c9.camel@j-davis.com>
Subject: Re: New strategies for freezing, advancing relfrozenxid early
From: Jeff Davis <pgsql@j-davis.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, John Naylor
 <john.naylor@enterprisedb.com>, Andres Freund <andres@anarazel.de>, Justin
 Pryzby <pryzby@telsasoft.com>, PostgreSQL Hackers
 <pgsql-hackers@lists.postgresql.org>
Date: Fri, 30 Dec 2022 12:43:04 -0800
In-Reply-To: 
 <CAH2-WzkTThXif2rcMLcBTqZNYLeJe-6dVVVC_SaTDWYTC3gdPg@mail.gmail.com>
References: 
	<CAH2-WznREt2q3P+D7bq4b0ytG_z6EOQUPNyoLB+CtEactZJPiA@mail.gmail.com>
	 <d0480c1e584150863fdecd9f83ed56a8b4e88a72.camel@j-davis.com>
	 <CAH2-WzmXErgxLmYrz9M90D79VjGq4OU8Fp52ECrqRyN_OF=f+A@mail.gmail.com>
	 <CAH2-Wzn6dhY3M4MomiABKZDxVC4m=7ub3A8cy3_13j2pJTv1=w@mail.gmail.com>
	 <CAH2-WzkU42GzrsHhL2BiC1QMhaVGmVdb5HR0_qczz0Gu2aSn=A@mail.gmail.com>
	 <20221111034455.GE16809@telsasoft.com>
	 <CAH2-Wz=-7_epivYdWN9F899iKKfgQ+zj8Myi7ZwBqMVsegRNJQ@mail.gmail.com>
	 <20221116052023.xg7pwgvx2t3hrgaj@awork3.anarazel.de>
	 <CAH2-Wzm_=mrWO+kUAJbR_gM_6RzpwVA8n8e4nh3dJGHdw_urew@mail.gmail.com>
	 <CAH2-WznS9TxXmz2_=SY+SyJyDFbiOftKofM9=aDo68BbXNBUMA@mail.gmail.com>
	 <20221206184255.dphhpvsyovqqwfdd@awork3.anarazel.de>
	 <CAH2-WznWcWn8FKE+oRqzf0XYx60uKmLmbPDh2VworajzJSVvuw@mail.gmail.com>
	 <CAH2-Wzn9KRf3rBSDkYsK3tvW2JegLfqCCG2Kwi4Ay9QVmhwPSA@mail.gmail.com>
	 <9fd17e87889845d74b8e3fdac7d2748a07950a92.camel@j-davis.com>
	 <CAH2-WzkvBdD13T+O1NFv97Pt-_kL3NxiAA9JZ5-nAFZS2xuZSA@mail.gmail.com>
	 <CAFBsxsGdfm5ot-GhgwF0YY8QyAjSZo5QtpeTDv4CSxbm7MfJbA@mail.gmail.com>
	 <CAH2-Wzng9JWoF4qUY2V37bfa2kogi8=GJO6B_bTfv3qaSGAhCw@mail.gmail.com>
	 <CAH2-WznQYscQth-0E+0CENhYF8_2_AKk4GWwhwiEnQ44xzhaww@mail.gmail.com>
	 <CAEze2WgrnTw2FmdPSGKoxaEDRrZ36aiz8C6=8P=stqZ2MjftDA@mail.gmail.com>
	 <CAH2-Wzk51g2=LvVxqKdhboLpPb2x4Coy4NJwh5mnQWcwV9e1gg@mail.gmail.com>
	 <CAH2-WzmjHQJ7pbdO4BtWVJ6CLG-Mp9CNe914WUJdiScOTNRKRw@mail.gmail.com>
	 <68df596638f60989cc72680d7029f0d51ca8cc19.camel@j-davis.com>
	 <CAH2-WzksXKMS=Nt7kHzZdnpXeQ6yTOLzbyL-qCUbGcZruqnm3w@mail.gmail.com>
	 <CAH2-WzmF9UVWv9Nmm3dhP7WS4=-qQSQRM-Jn2-NSr6z=sDsv3g@mail.gmail.com>
	 <a15cd7f9ca70a35b61faa38eccea9a7d41bdb3c2.camel@j-davis.com>
	 <CAH2-Wz=2w=qKxstssafra3bcEkjC_PRyT7w6VQAp-1MY7SazLQ@mail.gmail.com>
	 <CAH2-WznkNNj9hHTQUR4voNsSW7PKQzrjBe6DF0iCOUec+dU6Lg@mail.gmail.com>
	 <CAH2-WzkTThXif2rcMLcBTqZNYLeJe-6dVVVC_SaTDWYTC3gdPg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/acb89d4554f072f9dd30f2ae5b8b60092f3eb7c9.camel%40j-davis.com>
Precedence: bulk

On Mon, 2022-12-26 at 12:53 -0800, Peter Geoghegan wrote:
> * v12 merges together the code for the "freeze the page"
> lazy_scan_prune path with the block that actually calls
> heap_freeze_execute_prepared().
>=20
> This should make it clear that pagefrz.freeze_required really does
> mean that freezing is required. Hopefully that addresses Jeff's
> recent
> concern. It's certainly an improvement, in any case.

Better, thank you.

> * On a related note, comments around the same point in
> lazy_scan_prune
> as well as comments above the HeapPageFreeze struct now explain a
> concept I decided to call "nominal freezing". This is the case where
> we "freeze a page" without having any freeze plans to execute.
>=20
> "nominal freezing" is the new name for a concept I invented many
> months ago, which helps to resolve subtle problems with the way that
> heap_prepare_freeze_tuple is tasked with doing two different things
> for its lazy_scan_prune caller: 1. telling lazy_scan_prune how it
> would freeze each tuple (were it to freeze the page), and 2. helping
> lazy_scan_prune to determine if the page should become all-frozen in
> the VM. The latter is always conditioned on page-level freezing
> actually going ahead, since everything else in
> heap_prepare_freeze_tuple has to work that way.
>=20
> We always freeze a page with zero freeze plans (or "nominally freeze"
> the page) in lazy_scan_prune (which is nothing new in itself). We
> thereby avoid breaking heap_prepare_freeze_tuple's working assumption
> that all it needs to focus on what the page will look like after
> freezing executes, while also avoiding senselessly throwing away the
> ability to set a page all-frozen in the VM in lazy_scan_prune when
> it'll cost us nothing extra. That is, by always freezing in the event
> of zero freeze plans, we won't senselessly miss out on setting a page
> all-frozen in cases where we don't actually have to execute any
> freeze
> plans to make that safe, while the "freeze the page path versus don't
> freeze the page path" dichotomy still works as a high level
> conceptual
> abstraction.

I always understood "freezing" to mean that a concrete action was
taken, and associated WAL generated.

"Nominal freezing" is happening when there are no freeze plans at all.
I get that it's to manage control flow so that the right thing happens
later. But I think it should be defined in terms of what state the page
is in so that we know that following a given path is valid. Defining
"nominal freezing" as a case where there are no freeze plans is just
confusing to me.


--=20
Jeff Davis
PostgreSQL Contributor Team - AWS