Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(at)vondra(dot)me>, David Rowley <dgrowleyml(at)gmail(dot)com>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Date: 2026-04-20 20:28:03
Message-ID: CAAKRu_aXmbXQXvQdm0wBoixvUpJCCvP5DFABKc=qzDbA+D08pQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 20, 2026 at 3:00 PM Alexander Lakhin <exclusion(at)gmail(dot)com> 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 = 1
> autovacuum_analyze_threshold = 1
> debug_parallel_query = '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 = false to avoid vacuum
and analyze running after any of the other table scans may set some
pages all-visible

- Melanie

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-04-20 20:31:48 Re: [PATCH] Doc: Fix missing func_signature role in pg_get_tablespace_ddl entry
Previous Message Fabrízio de Royes Mello 2026-04-20 20:20:39 [PATCH] pg_surgery: Fix WAL corruption from concurrent heap_force_kill