On Mon, May 4, 2026 at 12:31 PM Daniil Davydov <[email protected]> wrote: > > On Sun, May 3, 2026 at 7:49 PM Jim Jones <[email protected]> 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
v22-0002-Prevent-access-to-other-sessions-temp-tables.patch
Description: Binary data
v22-0001-Add-tests-for-cross-session-temp-table-access.patch
Description: Binary data
