Re: Global temporary tables - Mailing list pgsql-hackers

On Tue, 7 Jul 2026 at 10:06, John Naylor <johncnaylorls@gmail.com> wrote:
>
> Okay, I followed up with various attempts to get the new sub XID
> tracking to do something dire, and couldn't find anything.
>

Unfortunately, it still wasn't working properly. In a fresh session,
doing VACUUM FREEZE on a GTT with ON COMMIT DELETE ROWS would fail
because the VACUUM FREEZE would update a new pg_temp_class tuple,
flushing it to the database, and then the ON COMMIT code would fail to
find it, because there was no intervening CommandCounterIncrement() to
make it visible.

I don't want to go round adding CommandCounterIncrement()'s to fix
things like this -- part of the reason for having the pending inserts
was to make that unnecessary. So instead, in v8, I have made it so
that the pending insert entries are kept up-to-date all the way to the
end of the transaction, even if they're flushed to the database before
that. This turns out to make the code far simpler, and easier to
reason about, as well as hopefully being more robust. So I feel much
better about this formulation of pending inserts.

> I did find something else, however:
>
> set statement_timeout  = '3s';
> set debug_discard_caches = 1;
>
> create global temporary table g (a int);
>
> This enters an infinite loop
>

Doh! Fixed in v8.

Regards,
Dean