RE: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows! - Mailing list pgsql-general

From Dolan, Sean
Subject RE: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows!
Date
Msg-id 6eec8fc3dfa743ff9b19d8ce0e87763d@lmco.com
Whole thread Raw
In response to Re: "No Free extents", table using all allocated space but no rows!  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows!  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-general
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
theaction.   Is there a way to see if there is a transaction on that table like you allude to?
 

-----Original Message-----
From: Laurenz Albe <laurenz.albe@cybertec.at> 
Sent: Wednesday, March 15, 2023 11:45 PM
To: Dolan, Sean (US N-ISYS Technologies Inc.) <sean.dolan@lmco.com>; pgsql-general@lists.postgresql.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
thatare not visible to your user, either because VACUUM didn't process the table yet, or because your snapshot is too
oldto 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

pgsql-general by date:

Previous
From: magog002@web.de
Date:
Subject: Aw: Re: Removing trailing zeros (decimal places) from a numeric (pre trim_scale()) with unexpected behaviour
Next
From: Dávid Suchan
Date:
Subject: Re: pg_upgrade Only the install user can be defined in the new cluster