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

From Laurenz Albe
Subject Re: "No Free extents", table using all allocated space but no rows!
Date
Msg-id c78803e2308015fcbedd36b4056f4cfeeb5f6816.camel@cybertec.at
Whole thread Raw
In response to "No Free extents", table using all allocated space but no rows!  ("Dolan, Sean" <sean.dolan@lmco.com>)
Responses RE: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows!  ("Dolan, Sean" <sean.dolan@lmco.com>)
List pgsql-general
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



pgsql-general by date:

Previous
From: Mark Hill
Date:
Subject: RE: uuid-ossp source or binaries for Windows
Next
From: Laurenz Albe
Date:
Subject: Re: Is the PL/pgSQL refcursor useful in a modern three-tier app?