Horton

Re: Global temporary tables

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

View thread View on postgr.es
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: Japin Li <japinli@hotmail.com>
Cc: Kirk Wolak <wolakk@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-07-01T07:32:37Z
Lists: pgsql-hackers 
On Wed, 1 Jul 2026 at 07:24, Japin Li <japinli@hotmail.com> wrote:
>
> Thanks for working on this.

Thank you for testing it!

> 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;
>
> Is this expected?

Ah yes, you're right. That's not good.

The root cause looks to be the same issue that Pavel reported -- the
ON COMMIT DELETE ROWS does a TRUNCATE when the transaction is
committed, which requires an AccessExclusiveLock. I think the patch
should reduce the lock level required for TRUNCATE on a global
temporary relation to RowExclusiveLock, like DELETE.

I'll try to post an update later this week.

Regards,
Dean

Commits

  1. doc: clarify MERGE PARTITIONS adjacency requirement