Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
| От | Álvaro Herrera |
|---|---|
| Тема | Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt |
| Дата | |
| Msg-id | 202510200724.udgwkvemgo7v@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt (jian he <jian.universality@gmail.com>) |
| Ответы |
Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
|
| Список | 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 по дате отправления: