Re: To what extent should tests rely on VACUUM ANALYZE?

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: To what extent should tests rely on VACUUM ANALYZE?
Date: 2024-03-29 12:00:00
Message-ID: 16b1dc26-addd-b97e-2a83-e7e7a5910558@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

29.03.2024 11:59, Alexander Lakhin wrote:
>
> But it looks like subselect is not the only test that can fail due to
> vacuum instability. I see that create_index also suffers from cranky
> ConditionalLockBufferForCleanup() (+if (rand() % 10 == 0)
> return false; ), although it placed in parallel_schedule before
> sanity_check, so this failure needs another explanation:
> -                      QUERY PLAN
> --------------------------------------------------------
> - Index Only Scan using tenk1_thous_tenthous on tenk1
> -   Index Cond: (thousand < 2)
> -   Filter: (tenthous = ANY ('{1001,3000}'::integer[]))
> -(3 rows)
> +                                      QUERY PLAN
> +--------------------------------------------------------------------------------------
> + Sort
> +   Sort Key: thousand
> +   ->  Index Only Scan using tenk1_thous_tenthous on tenk1
> +         Index Cond: ((thousand < 2) AND (tenthous = ANY ('{1001,3000}'::integer[])))
> +(4 rows)

I think that deviation can be explained by the fact that cost_index() takes
baserel->allvisfrac (derived from pg_class.relallvisible) into account for
the index-only-scan case, and I see the following difference when a test
run fails:
        relname        | relpages | reltuples | relallvisible | indisvalid | autovacuum_count | autoanalyze_count
 ----------------------+----------+-----------+---------------+------------+------------------+-------------------
- tenk1                |      345 |     10000 |           345 |            |                0 |                 0
+ tenk1                |      345 |     10000 |           305 |            |                0 |                 0

Best regards,
Alexander

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2024-03-29 12:21:32 Re: Synchronizing slots from primary to standby
Previous Message Hayato Kuroda (Fujitsu) 2024-03-29 11:48:29 RE: Improve eviction algorithm in ReorderBuffer