Re: Global temporary tables

Dean Rasheed <dean.a.rasheed@gmail.com>

From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: John Naylor <johncnaylorls@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-07-05T09:58:44Z
Lists: pgsql-hackers
On Sun, 5 Jul 2026 at 09:17, John Naylor <johncnaylorls@gmail.com> wrote:
>
> BEGIN;
>   SELECT count(*) FROM g;    -- first access here: queues g's pg_temp_class row
>                              -- (still unflushed inside this transaction)
>   SAVEPOINT s1;
>     DROP TABLE g;            -- removes that pending queue entry
>   ROLLBACK TO s1;            -- pg_class row is restored by MVCC;
>                              -- the queue entry is not restored
>   INSERT INTO g VALUES (1);  -- the table still works normally
> COMMIT;
>
> I'm starting to think the queue mechanism needs serious attention, if
> not a complete re-think.

Thanks for looking!

Yes, you're right. In that example, the pg_temp_class tuple gets lost
entirely. It really needs the same sort of sub XID tracking as the
usage/storage code, to ensure that they never get lost. I'll take a
look.

Regards,
Dean



Commits

  1. doc: clarify MERGE PARTITIONS adjacency requirement