MIME-Version: 1.0
References: <2be31f17-5405-4de9-8d73-90ebc322f7d8@vondra.me>
 <CAAKRu_Ypa7-JGVR+fstDxU5Cfitk_rf5ijdaqwtoPkztursufA@mail.gmail.com>
 <CAAKRu_ZrDadxmGepBwPZ03yAKnMxwsHYn8SK9Gg7VqigLLVUWg@mail.gmail.com>
 <CAApHDvqAOeOwCKh9g0gfxWa040=Hyc7_oA=C59rjod8kXJDWyw@mail.gmail.com>
 <CAAKRu_Yt76_HdfR6DtK_wtkSNSj9=VxSV_npt+6T2R=zTzp1Pg@mail.gmail.com>
 <CAAKRu_atv6zA274m8Ysgbfn49c0NbdvHT7nXvd9kroZKnFq8Dg@mail.gmail.com>
 <CAApHDvq_R-gNXu+06GQW6w_HaEMh1pezsyiCh7GNhgh+h0UqMw@mail.gmail.com>
 <CAAKRu_YfoGTHNn0XxA+dCPj9hyO96vO4Eb+awRR6T8m22qC6ww@mail.gmail.com>
 <97529f5a-ec10-46b1-ab50-4653126c6889@gmail.com>
 <46733d68-aec0-4d09-8120-4c66b87047a4@gmail.com>
 <jfkklcxtlddx45vgx7rr27wndhkrh5umm4d2f2nhuz46lhw5ys@ohru3zfkeuww>
 <e71cf1ab-92cc-479a-b1e9-39f663867b90@gmail.com>
 <CAAKRu_aoK6824z_JtJUWMZk2ST2dXN005Gkt05iitTLD2i4OCw@mail.gmail.com>
 <71277259-264e-4983-a201-938b404049d7@gmail.com>
In-Reply-To: <71277259-264e-4983-a201-938b404049d7@gmail.com>
From: Melanie Plageman <melanieplageman@gmail.com>
Date: Mon, 20 Apr 2026 16:28:03 -0400
Message-ID: 
 <CAAKRu_aXmbXQXvQdm0wBoixvUpJCCvP5DFABKc=qzDbA+D08pQ@mail.gmail.com>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM
 on-access)
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas@vondra.me>,
	David Rowley <dgrowleyml@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>,
	Chao Li <li.evan.chao@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>,
	Xuneng Zhou <xunengzhou@gmail.com>, Robert Haas <robertmhaas@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAAKRu_aXmbXQXvQdm0wBoixvUpJCCvP5DFABKc%3DqzDbA%2BD08pQ%40mail.gmail.com>
Precedence: bulk

On Mon, Apr 20, 2026 at 3:00=E2=80=AFPM Alexander Lakhin <exclusion@gmail.c=
om> wrote:
>
> I think, I found another test which suffers from autoanalyze with the new
> behavior: [1], [2].

Thanks for continuing to look for these!

> Initially I reproduced this diff on a slow armv7 device after many
> iterations of `make check` with:
> autovacuum_naptime =3D 1
> autovacuum_analyze_threshold =3D 1
> debug_parallel_query =3D 'regress'
>
> But now I see that it can be reproduced on an ordinary machine with just:
> --- a/src/test/regress/sql/plancache.sql
> +++ b/src/test/regress/sql/plancache.sql
> @@ -208,2 +208,3 @@ execute test_mode_pp(1); -- 2x
>  execute test_mode_pp(1); -- 3x
> +analyze test_mode;
>  execute test_mode_pp(1); -- 4x
> (and expected/plancache.out updated)
>
> and `make check` running in a loop. It failed for me on iterations 5, 4,
> 10 (as far as I can see, analyze updates relallvisible not every time):

If you do vacuum test_mode instead, it should fail reliably.

I think we can avoid having relallvisible updated by doing two things:
1) moving the analyze test_mode above the create index because the
create index will scan the table and could set pages all-visible and
then the analyze may update the statistics
2) create the table with autovacuum_enabled =3D false to avoid vacuum
and analyze running after any of the other table scans may set some
pages all-visible

- Melanie