Re: BUG with accessing to temporary tables of other sessions still exists - Mailing list pgsql-hackers

Hi

During testing this patch I also noticed that other sessions are also
able to drop the temporary table.


postgres=# drop table pg_temp_0.empty_table;
DROP TABLE

Above command works just fine from the other session.

I was able to fix that by adding the same check in
heap_drop_with_catalog in heap.c,  but I'm not sure whether it's the
right place to add this check.


@@ -1847,6 +1847,11 @@ heap_drop_with_catalog(Oid relid)
         */
        rel = relation_open(relid, AccessExclusiveLock);

+       if (RELATION_IS_OTHER_TEMP(rel))
+               ereport(ERROR,
+                               (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
+                               errmsg("cannot access temporary tables
of other sessions")));
+
        /*
         * There can no longer be anyone *else* touching the relation, but we
         * might still have open queries or cursors, or pending
trigger events, in

Let me know if I am missing something.

Thanks
Imran Zaheer




On Wed, Jun 3, 2026 at 8:51 PM Daniil Davydov <3danissimo@gmail.com> wrote:
>
> Hi,
>
> On Wed, Jun 3, 2026 at 10:20 PM Jim Jones <jim.jones@uni-muenster.de> wrote:
> >
> > Session 1 here does not create a temporary table (most likely a copy &
> > paste error), but I could reproduce this error as you suggested:
> >
>
> Sorry, I wrote it manually and forgot to specify "TEMP". It is implied here,
> of course.
>
> >
> > At a first glance the check seems reasonable. One tiny wording nit: the
> > comment in ExtendBufferedRelLocal says "... covering any attempt to
> > extend local relation.", but to avoid any confusing with the meaning of
> > RELATION_IS_LOCAL I'd argue that "covering any attempt to extend a
> > temporary relation" would be slightly clearer.
> >
>
> Thanks for looking into this! I agree with your comment.
>
> Please, see v2 patch with fixed comment.
>
> --
> Best regards,
> Daniil Davydov