Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
Date
Msg-id 202510200724.udgwkvemgo7v@alvherre.pgsql
Whole thread Raw
In response to Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt  (jian he <jian.universality@gmail.com>)
Responses Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
List pgsql-hackers
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)



pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Should we say "wal_level = logical" instead of "wal_level >= logical"
Next
From: Fujii Masao
Date:
Subject: Clarification on pg_dump behavior for security labels and policies on extension objects