On 3/28/24 16:00, Alexander Lakhin wrote: > ... > > Using the trick Thomas proposed in [1] (see my modification attached), I > could reproduce the failure easily on my workstation with no specific > conditions: > 2024-03-28 14:05:13.792 UTC client backend[2358012] > pg_regress/test_setup LOG: !!!ConditionalLockBufferForCleanup() > returning false > 2024-03-28 14:05:13.792 UTC client backend[2358012] > pg_regress/test_setup CONTEXT: while scanning block 29 of relation > "public.tenk2" > 2024-03-28 14:05:13.792 UTC client backend[2358012] > pg_regress/test_setup STATEMENT: VACUUM ANALYZE tenk2; > ... > relname | relpages | reltuples | autovacuum_count | autoanalyze_count > ---------+----------+-----------+------------------+------------------- > - tenk2 | 345 | 10000 | 0 | 0 > + tenk2 | 345 | 9996 | 0 | 0 > (1 row) > > So it looks to me like a possible cause of the failure, and I wonder > whether checks for query plans should be immune to such changes or results > of VACUUM ANALYZE should be 100% stable? >
Yeah. I think it's good to design the data/queries in such a way that the behavior does not flip due to minor noise like in this case. But I'm a bit confused - how come the estimates do change at all? The analyze simply fetches 30k rows, and tenk only has 10k of them. So we should have *exact* numbers, and it should be exactly the same for all the analyze runs. So how come it changes like this? regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
