Hi, Dean
Thanks for working on this. On Fri, 26 Jun 2026 at 20:37, Dean Rasheed <[email protected]> wrote: > On Fri, 26 Jun 2026 at 04:52, Kirk Wolak <[email protected]> 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.
