RE: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows!

I messed up and confused issues. The error is :
ERROR: Could not extend pg_tblspc/16555/PG_13_20200/xxxx/xxxx No space left on device
HINT: Check free disk space

So the schema is "full" and the offender is this one table. I can't TRUNCATE as there needs to be space to perform the action. Is there a way to see if there is a transaction on that table like you allude to?

-----Original Message-----
From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Sent: Wednesday, March 15, 2023 11:45 PM
To: Dolan, Sean (US N-ISYS Technologies Inc.) <sean(dot)dolan(at)lmco(dot)com>; pgsql-general(at)lists(dot)postgresql(dot)org
Subject: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows!

On Thu, 2023-03-16 at 01:58 +0000, Dolan, Sean wrote:
> Environment: PostGres 13 on RedHat 7.9.
>  
> I am using logical replication (publisher/subscriber) between two
> databases and there are times where one of our schemas gets to 100% of allocated space (No Free Extents).
> I went into the schema and did a \dt+ to see the amount of size being
> used and I could see one of the tables somehow shows 16GB, essentially the amount of allocated size.
> Wanting to see what is in that table, I did a simple select * from the
> table and it returns no rows.  Doing a count(*) also returns 0 rows.
>  
> How can the table be using all that space but there is nothing “in” the table?
> I don’t care about the data (as I am testing) so I can drop and recreate that one table.
> \dt+ would then show 0 bytes.    Later, I will then create a
> subscription and then I will get a No Free Extents error again and again the table has filled up.
>  
> What can I look for?

I don't think that there is an error message "no free extents".

It can easily happen that a table is large, but SELECT count(*) returns 0.
That would mean that either the table is empty and VACUUM truncation didn't work, or that the table contains tuples that are not visible to your user, either because VACUUM didn't process the table yet, or because your snapshot is too old to see the data, or because the transaction that created the rows is still open.

If you don't care about the data, your easiest option is to TRUNCATE the table.
If TRUNCATE is blocked, kill all transactions that block it.

Yours,
Laurenz Albe