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-07T22:37:11Z
Lists: pgsql-hackers
Attachments
- v8-0001-Save-temporary-table-ON-COMMIT-actions-to-pg_clas.patch (text/x-patch) patch v8-0001
- v8-0002-Basic-support-for-global-temporary-tables.patch (text/x-patch) patch v8-0002
- v8-0003-Support-indexes-on-global-temporary-tables.patch (text/x-patch) patch v8-0003
- v8-0004-Support-global-temporary-sequences.patch (text/x-patch) patch v8-0004
- v8-0005-Support-global-temporary-catalog-tables-and-add-p.patch (text/x-patch) patch v8-0005
- v8-0006-Add-relation-statistics-columns-to-pg_temp_class.patch (text/x-patch) patch v8-0006
- v8-0007-Add-relfrozenxid-and-relminmxid-columns-to-pg_tem.patch (text/x-patch) patch v8-0007
- v8-0008-Add-pg_temp_statistic-global-temporary-catalog-ta.patch (text/x-patch) patch v8-0008
- v8-0009-Add-pg_temp_statistic_ext_data-global-temporary-c.patch (text/x-patch) patch v8-0009
- v8-0010-Add-pg_temp_index-global-temporary-catalog-table.patch (text/x-patch) patch v8-0010
On Tue, 7 Jul 2026 at 10:06, John Naylor <johncnaylorls@gmail.com> wrote: > > Okay, I followed up with various attempts to get the new sub XID > tracking to do something dire, and couldn't find anything. > Unfortunately, it still wasn't working properly. In a fresh session, doing VACUUM FREEZE on a GTT with ON COMMIT DELETE ROWS would fail because the VACUUM FREEZE would update a new pg_temp_class tuple, flushing it to the database, and then the ON COMMIT code would fail to find it, because there was no intervening CommandCounterIncrement() to make it visible. I don't want to go round adding CommandCounterIncrement()'s to fix things like this -- part of the reason for having the pending inserts was to make that unnecessary. So instead, in v8, I have made it so that the pending insert entries are kept up-to-date all the way to the end of the transaction, even if they're flushed to the database before that. This turns out to make the code far simpler, and easier to reason about, as well as hopefully being more robust. So I feel much better about this formulation of pending inserts. > I did find something else, however: > > set statement_timeout = '3s'; > set debug_discard_caches = 1; > > create global temporary table g (a int); > > This enters an infinite loop > Doh! Fixed in v8. Regards, Dean
Commits
-
doc: clarify MERGE PARTITIONS adjacency requirement
- 57f19774d6c8 master cited