PostgreSQL temp table blues

From: Jahwan Kim <blgl13(dot)net(at)gmail(dot)com>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: PostgreSQL temp table blues
Date: 2019-03-13 07:02:58
Message-ID: CADU5SwN6K19VqA1jm7M7f9jK+G6Kbu13sBBcH2y6K0xurifOpA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi all,

I'd like to share my (painful) experience, in which temp tables caused
PostgreSQL shutdown.
TL;DR. Do not use temp tables in PostgreSQL with connection pool.

* My app uses connection pool AND temp tables, with default setting of ON
COMMIT PRESERVE ROWS.
* I found out later that autovacuum doesn't deal with temp tables.
* The database ages as long as the connection is not closed.
* So when the database age reaches XID STOP LIMIT, the database refuses to
process any new transaction requests, saying "database is not accepting
commands to avoid wraparound data loss... HINT: Stop the postmaster and use
a standalone backend to vacuum that database. "

After reading the docs, I expected this much. What happens after this
surprised me.
* Now the database needs to be shutdown. When shutting down, it tries to
remove temp tables (of course), but since the database is not accepting any
commands, ... The temp tables are then ORPHANED, although there was no
database crash!
* Because of these orphan temp tables, vacuuming the database in single
mode won't work, as suggested by HINT. The orphaned temp tables must be
manually dropped in single mode, and only then the database can be vacuumed
back to normal state. Without dropping temp tables, vacuuming just takes
(quite possibly a long) time and do (almost) nothing.

Well, that's all. All of the above facts are documented, albeit tersely. If
anybody I know ask me about temp tables in PostgreSQL, I'd just say "DON'T."

Best Regards,
Jahwan

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2019-03-13 08:49:40 Re: xmin and very high number of concurrent transactions
Previous Message Rashmi V Bharadwaj 2019-03-13 06:19:25 Re: PostgreSQL logical replication slot LSN values