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 →
  1. Prevent assertion failure in contrib/pg_freespacemap.

  2. Don't try to open visibilitymap when analyzing a foreign table