| From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
|---|---|
| To: | John Naylor <johncnaylorls(at)gmail(dot)com> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Global temporary tables |
| Date: | 2026-07-05 09:58:44 |
| Message-ID: | CAEZATCXz3TCmjH=KfehyKrXrJkCf8TsgeE5S4v7O+g6vb87KVg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 5 Jul 2026 at 09:17, John Naylor <johncnaylorls(at)gmail(dot)com> wrote:
>
> BEGIN;
> SELECT count(*) FROM g; -- first access here: queues g's pg_temp_class row
> -- (still unflushed inside this transaction)
> SAVEPOINT s1;
> DROP TABLE g; -- removes that pending queue entry
> ROLLBACK TO s1; -- pg_class row is restored by MVCC;
> -- the queue entry is not restored
> INSERT INTO g VALUES (1); -- the table still works normally
> COMMIT;
>
> I'm starting to think the queue mechanism needs serious attention, if
> not a complete re-think.
Thanks for looking!
Yes, you're right. In that example, the pg_temp_class tuple gets lost
entirely. It really needs the same sort of sub XID tracking as the
usage/storage code, to ensure that they never get lost. I'll take a
look.
Regards,
Dean
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuya Kawata | 2026-07-05 10:26:36 | Re: Improving display of octal GUCs |
| Previous Message | ZizhuanLiu X-MAN | 2026-07-05 09:00:53 | Re: support create index on virtual generated column. |