Re: BUG with accessing to temporary tables of other sessions still exists

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(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Wed, Jun 3, 2026 at 10:20 PM Jim Jones <jim(dot)jones(at)uni-muenster(dot)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