Re: BUG #18866: Running pg_freespace() on views triggers an Abort

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: "Euler Taveira" <euler@eulerto.com>
Cc: "Tender Wang" <tndrwang@gmail.com>, tharakan@gmail.com, pgsql-bugs@lists.postgresql.org, "Heikki Linnakangas" <hlinnaka@iki.fi>
Date: 2025-03-26T16:00:59Z
Lists: pgsql-bugs
"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 ;-)

Looking at other places where we throw an error for !RELKIND_HAS_STORAGE:

rawpage.c:
                (errcode(ERRCODE_WRONG_OBJECT_TYPE),
                 errmsg("cannot get raw page from relation \"%s\"",

pgstatindex.c:

                (errcode(ERRCODE_WRONG_OBJECT_TYPE),
                 errmsg("cannot get page count of relation \"%s\"",

tid.c:
                errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
                errmsg("cannot look at latest visible tid for relation \"%s.%s\"",

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.

			regards, tom lane



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