Re: XX000: tuple concurrently deleted during DROP STATISTICS
Tomas Vondra <tomas.vondra@enterprisedb.com>
From: Tomas Vondra <tomas.vondra@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org
Date: 2023-11-08T19:16:05Z
Lists: pgsql-hackers
Attachments
- drop-statistics-lock-fix.patch (text/x-patch) patch
On 11/8/23 16:52, Tom Lane wrote: > Tomas Vondra <tomas.vondra@enterprisedb.com> writes: >> 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: > > Shouldn't DROP STATISTICS be taking a lock on the associated table > that is strong enough to lock out ANALYZE? > Yes, I think that's the correct thing to do. I recall having a discussion about this with someone while working on the patch, leading to the current code. But I haven't managed to find that particular bit in the archives :-( Anyway, the attached patch should fix this by getting the lock, I think. - RemoveStatisticsById is what gets called drop DROP STATISTICS (or for dependencies), so that's where we get the AE lock - RemoveStatisticsDataById gets called from ANALYZE, so that already should have a lock (so no need to acquire another one) regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Lock table in DROP STATISTICS
- 4f8d3c5b5ade 12.18 landed
- 1e468ea4eace 13.14 landed
- 9dd50e92ed23 14.11 landed
- 0177fc773e3c 15.6 landed
- ee32b824dcc1 16.2 landed
- 28f84f72fbaf 17.0 landed