Re: XX000: tuple concurrently deleted during DROP STATISTICS
От | Tomas Vondra |
---|---|
Тема | Re: XX000: tuple concurrently deleted during DROP STATISTICS |
Дата | |
Msg-id | 5e68b429-f227-f252-4377-78e2f7d07905@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: XX000: tuple concurrently deleted during DROP STATISTICS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: XX000: tuple concurrently deleted during DROP STATISTICS
|
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: