Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)
От | Tomas Vondra |
---|---|
Тема | Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c) |
Дата | |
Msg-id | 79817e57-d670-8eb4-b3bc-0683f2688adc@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)
|
Список | pgsql-hackers |
On 2/13/22 22:43, Andres Freund wrote: > Hi, > > On 2022-02-13 18:21:38 -0300, Ranier Vilela wrote: >> Why open and lock the table Extended Statistics if it is not the owner. >> Check and return to avoid this. > > I was about to say that this opens up time-to-check-time-to-use type > issues. But it's the wrong thing to lock to prevent those. > I doubt optimizing this is worth any effort - ALTER STATISTICS is rare, not doing it with owner rights is even rarer. > Having looked briefly at it, I don't understand what the locking scheme is? > Shouldn't there be at least some locking against concurrent ALTERs and between > ALTER and ANALYZE etc? > I don't recall the details of the discussion (if at all), but if you try to do concurrent ALTER STATISTICS, that'll end up with: ERROR: tuple concurrently updated reported by CatalogTupleUpdate. AFAIK that's what we do for other object types that don't have a relation that we might lock (e.g. try to co CREATE OR REPLACE FUNCTION). ANALYZE reads the statistics from the catalog, so it should see the last committed stattarget value, I think. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: