| From: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Global temporary tables |
| Date: | 2026-07-06 21:53:51 |
| Message-ID: | CAN4CZFMSMJ5MuY_FsDvSF6_1P=Rur4sOMo2O+gtsgdXee4itvA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello!
This is a great feature, I did some testing of it.
1. If a table has an ON COMMIT clause:
CREATE GLOBAL TEMPORARY TABLE gtt_del (id int) ON COMMIT DELETE ROWS
Then pg_dump forgets that.
2. Even an aborted transaction pins frozenxid:
CREATE GLOBAL TEMPORARY TABLE gtt (id int);
In one session
BEGIN; SELECT count(*) FROM gtt; ABORT;
-- and keep session alive
Then in another session,
SELECT datfrozenxid FROM pg_database WHERE datname=current_database();
-- do some work
VACUUM (FREEZE);
SELECT datfrozenxid FROM pg_database WHERE datname=current_database();
-- ...
And repeat the above a few times for the second session, datfrozenxid
will remain the same until the first session is closed.
3. in AtEOSubXact_UsageCleanup and also in AtEOSubXact_StorageCleanup
+ else
+ gtr_remove_usage(entry->relid);
+ }
+
+ /* Update the usage stopped subid */
+ if (entry->stopped_subid == mySubid)
+ {
+ if (isCommit)
+ entry->stopped_subid = parentSubid;
+ else
+ entry->stopped_subid = InvalidSubTransactionId;
+ }
if we follow the else branch with gtr_remove_usage, shouldn't the
function immediately return?
4. in AtEOSubXact_PendingInsertCleanup
+ else
+ hash_search(pending_inserts, &entry->relid, HASH_REMOVE, NULL);
+ }
+
+ /* Update the inserted subid (may rollback flush) */
+ if (entry->inserted_subid == mySubid)
+ {
+ if (isCommit)
+ entry->inserted_subid = parentSubid;
+ else
+ {
+ entry->inserted_subid = InvalidSubTransactionId;
+ have_inserts_to_flush = true;
+ }
+ }
same question, isn't the else branch missing a return?
5. in gtr_remove_usage / gtr_remove_all_usage_on_exit
+ shared_entry = dshash_find(gtr_shared_usage, &key, true);
+
+ if (shared_entry->usage_count > 1)
and in gtr_record_usage
+ /* Flag the usage entry for eoxact cleanup */
+ EOXactUsageListAdd(relid);
+
+ /* Add/update shared usage entry */
+ key.dbid = MyDatabaseId;
+ key.relid = relid;
+ shared_entry = dshash_find_or_insert(gtr_shared_usage, &key, &found);
Can't this crash with a null pointer access in the above if
dshash_find_or_insert fails with OOM?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-07-06 22:07:35 | Re: File locks for data directory lockfile in the context of Linux namespaces |
| Previous Message | Jelte Fennema-Nio | 2026-07-06 21:35:56 | Re: Make \d tablename fast again, regression introduced by 85b7efa1cdd |