"No Free extents", table using all allocated space but no rows!
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? Thank you
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// 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 Sent: Wednesday, March 15, 2023 11:45 PM To: Dolan, Sean (US N-ISYS Technologies Inc.) ; 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 +, 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
Many logical replication synchronization worker threads kicking off for ONE table
The initial email below was the end result of something "run-away" in my logical replication. PostGres 13.6, RedHat 7.9 Database A is the publisher; Database B is the subscriber.Within Database A are multiple schemas and the publication ensures that all the schemas and its tables are added.There is one table in particular that has 1.4million rows of data. I create a subscription on Database B and can see in the log: LOG: logical replication table synchronization for subscription "sub_to_dbaseA", table "alert_history" has started. CONTEXT: COPY alert_history line 6668456 LOG: logical replication table synchronization for subscription "sub_to_dbaseA", table "alert_history" has started. CONTEXT: COPY alert_history line 5174606 LOG: logical replication table synchronization for subscription "sub_to_dbaseA", table "alert_history" has started. CONTEXT: COPY alert_history line 4325283 Normally I would see a line for "finished", but I never do. I then actively watch the schema/table and do \dt+ and can see that table grow in 2GB increments until I fill up the entire drive and run out of room for that schema. I am NOT getting any "checkpoints are occurring too frequently"As I have updated my WAL size: max_wal_size=4GB min_wal_size=1GB Is the system having trouble synching this amount of data in a quick fashion and therefore kicks off more synchronization threads? Anything I can do to prevent this? Thank you -Original Message- From: Laurenz Albe Sent: Thursday, March 16, 2023 1:25 PM To: Dolan, Sean (US N-ISYS Technologies Inc.) ; pgsql-general@lists.postgresql.org Subject: EXTERNAL: Re: EXTERNAL: Re: "No Free extents", table using all allocated space but no rows! On Thu, 2023-03-16 at 13:20 +, Dolan, Sean wrote: > I messed up and confused issues. The error is : > ERROR: Could not extend pg_tblspc/16555/PG_13_20200// 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? Ah, that's different. If you don't have enough space to run TRUNCATE, and you don't feel like extending the disk space, DROP TABLE would be a convenient alternative. Yours, Laurenz Albe
