On 11/8/23 16:10, Justin Pryzby wrote:
> I found this in our logs, and reproduced it under v11-v16.
>
> CREATE TABLE t(a int, b int);
> INSERT INTO t SELECT generate_series(1,999);
> CREATE STATISTICS t_stats ON a,b FROM t;
>
> while :; do psql postgres -qtxc "ANALYZE t"; done &
> while :; do psql postgres -qtxc "begin; DROP STATISTICS t_stats"; done &
>
> It's known that concurrent DDL can hit elog(). But in this case,
> there's only one DDL operation.
>
AFAICS this happens because store_statext (after ANALYZE builds the new
statistics) does this:
----------------------------
/*
* Delete the old tuple if it exists, and insert a new one. It's easier
* than trying to update or insert, based on various conditions.
*/
RemoveStatisticsDataById(statOid, inh);
/* form and insert a new tuple */
stup = heap_form_tuple(RelationGetDescr(pg_stextdata), values, nulls);
CatalogTupleInsert(pg_stextdata, stup);
----------------------------
So it deletes the tuple first (if there's one), and then inserts the new
statistics tuple.
We could update the tuple instead, but that would be more complex (as
the comment explains), and it doesn't actually fix anything because then
simple_heap_delete just fails with TM_Updated instead.
I think the only solution would be to lock the statistics tuple before
running ANALYZE, or something like that. Or maybe we should even lock
the statistics object itself, so that ANALYZE and DROP can't run
concurrently on it?
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company