Re: BUG #18866: Running pg_freespace() on views triggers an Abort
Euler Taveira <euler@eulerto.com>
From: "Euler Taveira" <euler@eulerto.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Tender Wang" <tndrwang@gmail.com>, tharakan@gmail.com,
pgsql-bugs@lists.postgresql.org, "Heikki Linnakangas" <hlinnaka@iki.fi>
Date: 2025-03-26T16:51:51Z
Lists: pgsql-bugs
On Wed, Mar 26, 2025, at 1:00 PM, Tom Lane wrote: > "Euler Taveira" <euler@eulerto.com> writes: > > Your patch needs some adjustments. There is no need to include pg_class.h. I > > don't like the proposed error message. I prefer saying the relation cannot be > > opened because that's what will happen if it reaches this code path. > > I don't care for that proposal either: we just did open the relation ;-) Fair point. > relcache.c: > elog(ERROR, "relation \"%s\" does not have storage", > RelationGetRelationName(relation)); > > So the previous proposal was evidently modeled on the first two of > these precedents. Personally I prefer messages that say *why* > something failed, so I'd go with something more like "relation \"%s\" > does not have storage". Use of errdetail_relkind_not_supported is > fine though. I thought about saying "no storage" but don't know why was convinced by that proposal. Your suggestion works for me. -- Euler Taveira EDB https://www.enterprisedb.com/
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Prevent assertion failure in contrib/pg_freespacemap.
- db8238da4265 13.21 landed
- 5ff827389e77 14.18 landed
- 51d038da8280 17.5 landed
- 4623d71443de 18.0 landed
- 41ed749e48b0 16.9 landed
- 0e86bad38099 15.13 landed
-
Don't try to open visibilitymap when analyzing a foreign table
- 049ef3398d05 17.0 cited