Re: XX000: tuple concurrently deleted during DROP STATISTICS
От | Tomas Vondra |
---|---|
Тема | Re: XX000: tuple concurrently deleted during DROP STATISTICS |
Дата | |
Msg-id | c267aeae-c21e-c7d4-5eb6-735b1008bbce@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 20:58, Tom Lane wrote: > Tomas Vondra <tomas.vondra@enterprisedb.com> writes: >> On 11/8/23 16:52, Tom Lane wrote: >>> 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. > > This looks generally correct, but surely we don't need it to be as > strong as AccessExclusiveLock? There seems no reason to conflict with > ordinary readers/writers of the table. > > ANALYZE takes ShareUpdateExclusiveLock, and offhand I think this > command should do the same. > Right. I did copy that from DROP TRIGGER code somewhat mindlessly, but you're right this does not need block readers/writers. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: