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

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tomas Vondra <tv(at)fuzzy(dot)cz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)
Date: 2022-02-13 22:27:59
Message-ID: CAEudQAo1sJ4aJv=sTN-Qu95F+CK6Oymhah5vqCmBEKx-+HtTxA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em dom., 13 de fev. de 2022 às 18:43, Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-02-13 22:55:26 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set
Previous Message Thomas Munro 2022-02-13 22:23:18 Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set