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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: Mark all GUC variable as PGDLLIMPORT
Следующее
От: Andres Freund
Дата:
Сообщение: bailing out in tap tests nearly always a bad idea