Re: Fix bug with accessing to temporary tables of other sessions

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Daniil Davydov <3danissimo(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Soumya S Murali <soumyamurali(dot)work(at)gmail(dot)com>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stepan Neretin <slpmcf(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Mohamed Ali <moali(dot)pg(at)gmail(dot)com>, Nazneen Jafri <jafrinazneen(at)gmail(dot)com>, Shawn McCoy <shawn(dot)the(dot)mccoy(at)gmail(dot)com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
Date: 2026-05-02 16:34:00
Message-ID: CAPpHfds8pwuwF69JFs0SQz58op-U4ddR3KWv0NVEij2mpkzgpw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, May 2, 2026 at 6:37 PM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
> On Sat, May 2, 2026 at 9:16 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> >
> > Thank you for your feedback. I think the scope of this patch is well
> > described in [1]. We don't want to restrict the superuser from
> > something, but our buffer manager just technically can't access the
> > local buffers of other sessions. Read streams introduced a new code
> > path for reading relations, which was lacking of the proper check for
> > local buffers of other sessions. And this patch attempts to fix that.
> > DROP TABLE is an exclusion. It actually don't need to read contents
> > of buffers, just drop them. And DropRelationBuffers() have a special
> > exclusion for this case. So, DROP TABLE appears to be the only
> > operation that makes sense, it's a conscious exclusion, and there is
> > no intention to forbid it.
>
> Yep, exactly.
>
> > I've revised the patch. 0001 contains tests and states the current
> > behavior. 0002 contains fix and the corresponding changes in the
> > tests. I made a change in 0001: removed the check in
> > ReadBufferExtended(). We added the same check to ReadBuffer_common(),
> > and I don't think it makes sense to do this check twice in the row.
>
> Thank you! But I'm afraid that you forgot to attach the patches..

Here they are.

> BTW, what do you think about this proposal? :
> > On the other hand, we have an error message that says "cannot access...", which
> > may look like every kind of "access" is forbidden. I bet that this is the place
> > that has confused you. More accurate error message would be "cannot access
> > pages..." or "cannot access content...". I think we can change our error
> > message in this way. What do you think?
>
> We can easily include it in the first patch.

This is possible, but I would keep that in a separate patch. We now
have clear scope for both patches: 0001 includes additional tests,
0002 fixes the bug and restores old behavior.

------
Regards,
Alexander Korotkov
Supabase

Attachment Content-Type Size
v20-0002-Prevent-access-to-other-sessions-temp-tables.patch application/octet-stream 8.8 KB
v20-0001-Add-tests-for-cross-session-temp-table-access.patch application/octet-stream 13.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2026-05-02 16:51:52 Re: Two issues leading to discrepancies in FSM data on the standby server
Previous Message Daniil Davydov 2026-05-02 15:37:35 Re: Fix bug with accessing to temporary tables of other sessions