Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)

Поиск
Список
Период
Сортировка
От Ranier Vilela
Тема Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)
Дата
Msg-id CAEudQAo1sJ4aJv=sTN-Qu95F+CK6Oymhah5vqCmBEKx-+HtTxA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Дерево обсуждения
Em dom., 13 de fev. de 2022 às 18:43, Andres Freund <andres@anarazel.de> escreveu:
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.

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 checked the pg_statistics_object_ownercheck function and I think the patch is wrong.
It seems to me that when using SearchSysCache1, it is necessary to open and lock the table.

Better remove the patch, sorry for the noise.

regards,
Ranier Vilela

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set