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