Hi,
In my recent SQLSmith test on HEAD, I found $SUBJECT.
The original query is too large and complex, and after reducing, I
found that the following short query can reproduce:
psql (19devel)
Type "help" for help.
postgres=# select NULLIF((SELECT score FROM pg_stat_autovacuum_scores LIMIT 1),
(SELECT score FROM pg_stat_autovacuum_scores LIMIT 1));
ERROR: detected double pfree in PgStat Snapshot 0x557d9926b400
Thanks to commit 095555d, this error can be surfaced. Before 095555d,
the above query succeeded.
I did research on this issue, and I found that after 5891c7a, the
PgStat_EntryRef can be cached if
stats_fetch_consistency > none.
If the value of stats_fetch_consistency is set to none, the query will
not report an error.
postgres=# set stats_fetch_consistency = none;
SET
postgres=# select NULLIF((SELECT score FROM pg_stat_autovacuum_scores LIMIT 1),
(SELECT score FROM pg_stat_autovacuum_scores LIMIT 1));
nullif
--------
(1 row)
If stats_fetch_consistency is cache or snapshot, when calling
pgstat_fetch_entry(),
the PgStat_EntryRef will be inserted into hash-table if it doesn't exist.
In relation_needs_vacanalyze(), at the end, the tabentry will be free if it
is not null.
In this case, we may get the same PgStat_EntryRef entry again from the
hash table, but it was pfree when it first appeared.
So, detected double pfree will be reported when pfree is called at the
end of relation_needs_vacanalyze().
If the pgstat_fetch_consistency > PGSTAT_FETCH_CONSISTENCY_NONE, we
should not free the entry.
I wrote a patch to fix this issue. Please see the attached patch.
--
Thanks,
Tender Wang
