Postgres Pro
Downloads
Home   >   mailing lists

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

From Ranier Vilela
Subject Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)
Date
Msg-id CAEudQAo1sJ4aJv=sTN-Qu95F+CK6Oymhah5vqCmBEKx-+HtTxA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Tree view
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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Next
From: Andres Freund
Date:
Subject: Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set