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-08T21:25:50Z
Lists: 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
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