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

On Mon, May 4, 2026 at 12:31 PM Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:
>
> On Sun, May 3, 2026 at 7:49 PM Jim Jones <jim(dot)jones(at)uni-muenster(dot)de> wrote:
> >
> > On 03/05/2026 10:53, Daniil Davydov wrote:
> > > Please, see the attached patch that ensures that cross-session LOCK TABLE works
> > > properly.
> >
> > I guess you should either add it to the 0001 sent by Alexander, or
> > create a 0003. Right now the cfbot is complaining, as
> > 013_temp_obj_multisession.pl still does not exist :)
> >
>
> OK, I'll attach this patch as a third one, just for review purposes. After
> agreement on its content, it should be included into the 0001 and 0002 patches.

Thank you. I've integrated your check into 0001, and added an
explicit check that the table gets removed once the lock by other
session is removed.

Let me do a quick summary:
* Our buffer manager is not capable for reading temp tables of other sessions.
* This was covered by explicit checks, but broken since b7b0f3f27241
introduced alternative code path for reading tables.
* This doesn't apply to DROP TABLE. DROP TABLE is a conscious
exclusion and the only operation we can do correctly for other
session' temp tables. There is an explicit exclusion in the code to
skip the attempt to cleanup buffers of other session' temp tables.
* This patchset consists of tests (0001) for various operations with
other session's temp tables including buggy behavior, and the fix
(0002) including changes for tests.

Thus, I don't see the reason why this shouldn't be committed and
backpatched to PG17 (first release containing b7b0f3f27241).
Opinions? Michael?

------
Regards,
Alexander Korotkov
Supabase