Re: Global temporary tables

Hi, Dean

Thanks for working on this.

On Fri, 26 Jun 2026 at 20:37, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
> On Fri, 26 Jun 2026 at 04:52, Kirk Wolak <wolakk(at)gmail(dot)com> wrote:
>>
>> + 1 for the idea. I will try to review this over the weekend. We could use this.
>
> Thanks. Any reviews will be very helpful.
>
> In the meantime, comparing the 2 patchsets, I realised that there was
> a bug in mine -- ON COMMIT DELETE ROWS wasn't working properly in all
> cases.
>
> More specifically, it was working for a global temporary table created
> in the current session, but disconnecting and then reconnecting caused
> it to stop working, because I hadn't realised that the ON COMMIT
> action of a temporary table is not saved to the database.
>
> Not saving the ON COMMIT action to the database kind-of made sense for
> old-style temporary tables, since they disappear at the end of the
> session. However, even then, it can be useful to have it in the
> database so that psql's \d meta-command can display it, and of course,
> for global temporary tables, saving it to the database is essential so
> that new sessions can pick it up.
>
> So here's a new patchset, where 0001 is new -- it saves a temporary
> table's ON COMMIT action to pg_class, and updates psql's \d to display
> it. I think we could commit that independently of the global temporary
> tables feature, since it seems somewhat useful by itself.
>
> (I chose to do it as a new column "reloncommit" in pg_class, rather
> than as a reloption, because a reloption didn't seem quite right for
> this, but that's a matter of opinion.)
>

While testing the v5 patch, I encountered a lock wait.

2026-07-01 14:18:43.603 CST [1486593] LOG: process 1486593 still waiting for AccessExclusiveLock on relation 16384 of database 5 after 1000.106 ms
2026-07-01 14:18:43.603 CST [1486593] DETAIL: Process holding the lock: 1486484. Wait queue: 1486593.
2026-07-01 14:18:43.603 CST [1486593] CONTEXT: waiting for AccessExclusiveLock on relation 16384 of database 5
2026-07-01 14:18:43.603 CST [1486593] STATEMENT: SELECT * FROM gtt_delete;

To reproduce:

Session 1:

CREATE GLOBAL TEMPORARY TABLE gtt_delete (id int) ON COMMIT DELETE ROWS;
BEGIN;
INSERT INTO gtt_delete VALUES (1);

Session 2:

SELECT * FROM gtt_delete; ---> blocked

Is this expected?

> Regards,
> Dean

--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.