How to fix Cannot vacuum "table": it is a temporary table in PostgreSQL

PostgreSQLINTERMEDIATEMEDIUMUpdated Dec 28, 2025· 104 views

PostgreSQL prevents automatic vacuuming of temporary tables since they are session-specific. Manual VACUUM calls within the same session are allowed, or you can use TRUNCATE for faster cleanup without requiring maintenance.

Quick fix

Fixes Cannot vacuum "table": it is a temporary table

CREATE TEMPORARY TABLE my_temp_table (
  id SERIAL PRIMARY KEY,
  data TEXT
);
  1. Verify the table is temporary
  2. Run VACUUM from the correct session
  3. Use TRUNCATE instead of DELETE + VACUUM
  4. Configure ON COMMIT behavior
postgresql — error
CREATE TEMPORARY TABLE my_temp_table (
  id SERIAL PRIMARY KEY,
  data TEXT
);
Cannot vacuum "table": it is a temporary table

What this error means

Temporary tables in PostgreSQL are session-scoped objects that only the creating database connection can see. Because the autovacuum daemon cannot access temporary tables, attempting an automatic VACUUM or running VACUUM from outside the session that created the table results in this error. This is a safety restriction to prevent cross-session interference with temporary objects. The error typically occurs when scripts or tools attempt to maintain a temporary table without accounting for the session-visibility constraint. Unlike regular tables, temporary tables have unique maintenance requirements because their data is automatically cleaned up when the session ends.

Typical symptoms

  • VACUUM command fails when attempted on a temporary table from outside its creation session
  • Error occurs even though VACUUM works fine on permanent tables
  • Autovacuum configuration settings do not apply to temporary tables
  • Long-running sessions with frequently updated temporary tables may accumulate dead rows

Common causes

  1. Attempting to run VACUUM on a temporary table from a different session than the one that created it
  2. Using database maintenance tools that automatically VACUUM all tables without excluding temporary ones
  3. Misunderstanding that autovacuum skips temporary tables entirely
  4. Running VACUUM in an administrative script that does not have access to the original session

How to fix "Cannot vacuum "table": it is a temporary table"

1Verify the table is temporary

Check if the table is defined as TEMPORARY or TEMP in your CREATE TABLE statement:

sql
CREATE TEMPORARY TABLE my_temp_table (
  id SERIAL PRIMARY KEY,
  data TEXT
);

You can also query the system catalog to confirm:

sql
SELECT tablename, relpersistence
FROM pg_tables
JOIN pg_class ON pg_tables.tablename = pg_class.relname
WHERE tablename = 'my_temp_table';
-- relpersistence = 't' means temporary
2Run VACUUM from the correct session

If you must vacuum the temporary table, do so from within the same session that created it:

sql
-- From the session that created the temporary table:
VACUUM my_temp_table;
ANALYZE my_temp_table;  -- optional, updates query planner statistics

Do not attempt to run this from a separate connection or administrative session.

3Use TRUNCATE instead of DELETE + VACUUM

For temporary tables where you need to regularly clear data, TRUNCATE is more efficient than DELETE followed by VACUUM:

sql
TRUNCATE my_temp_table;  -- Much faster, reclaims space immediately

This is particularly useful in stored procedures or applications that reuse temporary tables multiple times within a session.

4Configure ON COMMIT behavior

For frequently-reset temporary tables, use the ON COMMIT clause to automatically clear data:

sql
CREATE TEMPORARY TABLE my_temp_table (
  id SERIAL PRIMARY KEY,
  data TEXT
) ON COMMIT DELETE ROWS;  -- Automatically TRUNCATE at transaction end

This eliminates the need for manual VACUUM or TRUNCATE calls and prevents dead row accumulation.

5Exclude temporary tables from maintenance scripts

If you have scripts that VACUUM all tables, filter out temporary ones:

sql
-- Vacuum only permanent tables
VACUUM ANALYZE
WHERE relpersistence != 't';

-- Better approach: Use SELECT query to build dynamic VACUUM list
SELECT 'VACUUM ANALYZE ' || tablename || ';'
FROM pg_tables
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
  AND relpersistence != 't';  -- Exclude temporary tables

Advanced notes

Temporary tables are automatically cleaned up when their creating session ends, so VACUUM is only necessary for long-lived sessions that repeatedly modify the same temporary table over extended periods. For short-lived temporary tables used in quick operations, VACUUM is unnecessary overhead. If orphaned temporary tables are causing XID wraparound issues, consider implementing session cleanup mechanisms or reducing the lifetime of temporary tables. Some ORMs and database connection pools may create phantom temporary tables if sessions are not properly closed; ensure your application properly closes all database connections to prevent this scenario.

Frequently asked questions

What does "Cannot vacuum "table": it is a temporary table" mean?
Temporary tables in PostgreSQL are session-scoped objects that only the creating database connection can see. Because the autovacuum daemon cannot access temporary tables, attempting an automatic VACUUM or running VACUUM from outside the session that created the table results in this error. This is a safety restriction to prevent cross-session interference with temporary objects.
How do I fix "Cannot vacuum "table": it is a temporary table"?
PostgreSQL prevents automatic vacuuming of temporary tables since they are session-specific. Manual VACUUM calls within the same session are allowed, or you can use TRUNCATE for faster cleanup without requiring maintenance.
What causes "Cannot vacuum "table": it is a temporary table"?
Attempting to run VACUUM on a temporary table from a different session than the one that created it Using database maintenance tools that automatically VACUUM all tables without excluding temporary ones Misunderstanding that autovacuum skips temporary tables entirely
Is the "Cannot vacuum "table": it is a temporary table" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading