Re: Global temporary tables

Hi

pá 26. 6. 2026 v 21:37 odesílatel Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
napsal:

> 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.)
>

I am testing this patchset. Generally, it looks very well. I didn't see any
bloat on catalog

I found an issue - TRUNCATE waits when gtt is used by different
transactions, and TRUNCATE removes content in all sessions.

Is it expected?

Regards

Pavel

>
> Regards,
> Dean
>