Message-ID: <086c2108-0d46-4711-82df-19eb06a55326@uni-muenster.de>
Date: Fri, 10 Apr 2026 12:28:59 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Daniil Davydov <3danissimo@gmail.com>
Cc: Soumya S Murali <soumyamurali.work@gmail.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, Stepan Neretin <slpmcf@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
References: 
 <CAJDiXghdFcZ8=nh4G69te7iRr3Q0uFyXxb3ZdG09_GTNZXwH0g@mail.gmail.com>
 <CAJDiXgi7tWm_y0i7kD8fMxGe=86_W-hMxyQS+g7-7cdTzd-KRQ@mail.gmail.com>
 <CAMtXxw_ta_9i=uPJMvGueOBc04crmraJXcyJhN0K=Wu9aa2rog@mail.gmail.com>
 <1a32fc83-df78-4774-97dc-2bb06dbb16e9@uni-muenster.de>
 <3529398.1774273446@sss.pgh.pa.us>
 <CAJDiXgh9g4TEyF3kWCiBgHX6QbpATZtxTfrQuBCKxUO5=nZBOw@mail.gmail.com>
 <4075754.1774378690@sss.pgh.pa.us>
 <CAJDiXgihovkP6DMAFyJtYF4JSAjvKmiRVbF5R5n3SA=Yag32_w@mail.gmail.com>
 <CAMtXxw8pHLH9+mG3wxsF8f=Y+pHqTNP8X1UmZQPkRL9pZ5aF2w@mail.gmail.com>
 <67637cf8-8cbf-4f86-8775-52aa0329972d@uni-muenster.de>
 <b13dc5ba-6c11-429c-b6fe-673c1c767bcf@uni-muenster.de>
 <CAJDiXgiAObr4c+PTWSS19vcohrFSDLK3MC5FK3TekMB3U3DjfQ@mail.gmail.com>
 <e58a9580-7bbf-4d70-ad99-833fab77cf88@uni-muenster.de>
 <CAJDiXghBO_TqvHOSui8MOxiFmwLT20+SAnH5nW1rpWHk7Jwffg@mail.gmail.com>
 <402bbc8d-728b-4467-8024-31c2bc101ead@uni-muenster.de>
 <CAJDiXgi0JFk0f2KWWQkzLBC5P7erX9WP18qqnbi-rjZ-K-P=3w@mail.gmail.com>
Content-Language: de-DE, en-GB
From: Jim Jones <jim.jones@uni-muenster.de>
In-Reply-To: 
 <CAJDiXgi0JFk0f2KWWQkzLBC5P7erX9WP18qqnbi-rjZ-K-P=3w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/086c2108-0d46-4711-82df-19eb06a55326%40uni-muenster.de>
Precedence: bulk

Hi Daniil

On 10/04/2026 09:10, Daniil Davydov wrote:
> Having both checks might look a bit redundant since the read stream will
> eventually call the StartReadBuffersImpl function. On the other hand, there are
> many places which are checking this restriction even if subsequent functions
> (from bufmgr) also have this check.
> 
> So, I'll keep both checks and a bit reduce the comments in the bufmgr.c .

Putting this check a level deeper sounds good to me.

> BTW, what do you think about making this comment less "concrete"? :
> # SELECT via index scan from other session.
> # Sequential scans are blocked at read_stream_begin_relation(); index scans
> # bypass that path entirely and reach ReadBufferExtended() in bufmgr.c
> # (nbtree's _bt_getbuf calls ReadBuffer directly for individual page fetches).
> # enable_seqscan=off forces the planner to use the index.
> 
> I mean that if the described logic changes, this comment will become confusing.
> We can describe the test in general words. For example :
> # Index scans can use a different code path from the one sequential scans are
> # following. Make sure that we cannot access other sessions' temp tables during
> # index scan either.

+1

Yeah, it's indeed too verbose. I guess these comments were originally
just for me so I wouldn't get too confused along the way :)

I don't have anything else to add at this point. Unless there are any
objections, I'll mark the CF entry as 'Ready for Committer.'

Thanks!

Best, Jim