Re: misleading error message in ProcessUtilitySlow T_CreateStatsStmt
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Álvaro Herrera <alvherre@kurilemu.de>
Cc: jian he <jian.universality@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>,
Kirill Reshke <reshkekirill@gmail.com>
Date: 2025-08-28T21:46:39Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
CREATE STATISTICS: improve misleading error message
- cbd3732cbbaa 14.20 landed
- 4529861cc408 15.15 landed
- f30c04682cdf 16.11 landed
- f9b41f3e1ecd 17.7 landed
- 38883916e41c 18.0 landed
- 9ec0b29976b6 19 (unreleased) landed
- f9a7622483c3 15.15 landed
- f225473cbae2 19 (unreleased) landed
- e9fb314c7ad8 17.7 landed
- d84a6c3dad1f 16.11 landed
- b830f9d67463 14.20 landed
- 3eea4dc2c7cf 18.0 landed
-
Glossary: improve definition of "relation"
- 16a9165ce4a4 19 (unreleased) landed
-
Extended statistics on expressions
- a4d75c86bf15 14.0 cited
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de> writes: > I propose to use this report: > ERROR: cannot create statistics on specified relation > DETAIL: CREATE STATISTICS only supports tables, materialized views, foreign tables, and partitioned tables. WFM, although I think you could shorten it to "tables, materialized views, and foreign tables". We generally expect that partitioned tables are included when saying "tables", no? I'm not dead set on that either way, though. > While looking at this whole thing, I noticed that this code is somewhat > bogus in a different way: we're resolving the relation name twice, both > here in ProcessUtilitySlow() (to pass to transformStatsStmt), and later > again inside CreateStatistics(). It's really strange that we decided > not to pass the relation Oids as a list argument to CreateStatistics. I > suggest to change that as the first attached patch. I think this is a good idea, but I'm not sure that the locking considerations are straight in this version. Once we translate a relation name to OID, we'd better hold lock on the rel continuously to the end of usage of that OID. It looks like you do, but then couldn't the + rel = relation_open(relid, ShareUpdateExclusiveLock); in CreateStatistics use NoLock to signify that we expect to have the lock already? Alternatively, maybe the right fix is to move the parse-analysis work into CreateStatistics altogether. I think there is not a very good argument for ProcessUtilitySlow doing all that stuff. It's supposed to mainly just be a dispatching switch(), IMO. regards, tom lane