Feedback-ID: ie3de48e3:Fastmail
Date: Mon, 20 Oct 2025 09:31:38 +0200
From: =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
To: jian he <jian.universality@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Tom Lane <tgl@sss.pgh.pa.us>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Kirill Reshke <reshkekirill@gmail.com>
Subject: Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
Message-ID: <202510200724.udgwkvemgo7v@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CACJufxGsnzD1Hp1aTSaMoKq7kTifodn3ZiK8UF63SK1tE1LF=A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202510200724.udgwkvemgo7v%40alvherre.pgsql>
Precedence: bulk

On 2025-Oct-20, jian he wrote:

> On Fri, Oct 17, 2025 at 8:13 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:

> /*
>  * transformStatsStmt - parse analysis for CREATE STATISTICS
>  *
>  * To avoid race conditions, it's important that this function relies only on
>  * the passed-in rel (and not on stmt->relation) as the target relation.
>  */
> CreateStatsStmt *
> transformStatsStmt(Relation rel, CreateStatsStmt *stmt, const char *queryString)

> the (Relation rel) effectively comes from "stmt->relations", which
> conflict with the above comments.

Hmm?  It does not.  The whole point is that the relation name (RangeVar
stmt->relations) has already been resolved to an OID and locked, which
is what we pass as 'Relation rel'.  Trying to resolve the name to an OID
again opens us up for race conditions.  This is alleviated if the
relation has already been locked, so maybe we can relax this comment;
but it's not outright contradictory AFAICS.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Oh, great altar of passive entertainment, bestow upon me thy discordant images
at such speed as to render linear thought impossible" (Calvin a la TV)