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

Tender Wang <tndrwang@gmail.com>

From: Tender Wang <tndrwang@gmail.com>
To: tharakan@gmail.com, pgsql-bugs@lists.postgresql.org
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2025-03-25T15:45:07Z
Lists: pgsql-bugs

Attachments

PG Bug reporting form <noreply@postgresql.org> 于2025年3月25日周二 22:42写道:

> The following bug has been logged on the website:
>
> Bug reference:      18866
> Logged by:          Robins Tharakan
> Email address:      tharakan@gmail.com
> PostgreSQL version: Unsupported/Unknown
> Operating system:   Ubuntu
> Description:
>
> Hi,
>
> Passing a view to pg_freespace() triggers an Abort on HEAD. This has been
> so
> since the beginning (049ef3398d05c9dc8f48aa9a6d68440661cfeb87). Given that
> this is just an assert, feel free to skip - but thought I'd bring it up, in
> case this needs a review.
>
> SQL / Backtrace / Error Log excerpt given below:
>
>
> SQL
> ===
> $ cat crashing.sql
> CREATE EXTENSION pg_freespacemap;
> SELECT pg_freespace('pg_roles', 0);
>

Yeah, it would crash if you input a foreign table, for example:
create extension postgres_fdw;
CREATE SERVER d FOREIGN DATA WRAPPER postgres_fdw;
CREATE FOREIGN TABLE f (g text) SERVER d;
SELECT pg_freespace('f', 0);    -- will crash too

I think we can remove the Assert in smgropen().
Any thoughts?

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