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

Tender Wang <tndrwang@gmail.com>

From: Tender Wang <tndrwang@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Euler Taveira <euler@eulerto.com>, tharakan@gmail.com, pgsql-bugs@lists.postgresql.org, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2025-03-27T07:14:19Z
Lists: pgsql-bugs

Attachments

Tom Lane <tgl@sss.pgh.pa.us> 于2025年3月27日周四 00:01写道:

> "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.


Yes, I referred to the rawpage.c.


> 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.
>

 PFA for the updated patch file.

-- 
Thanks,
Tender Wang

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