MIME-Version: 1.0
References: <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>
 <CAMtXxw_hBNuAWQUdSRMpoeRVRYr+5+S7p0bSzuqtHxfpzJPd3w@mail.gmail.com>
 <b6614954-6c71-451a-a1d7-345d255b4afb@uni-muenster.de>
 <CAMtXxw_2VnP5U7U+2ObOCC2voEkAzUqAgH=rPTQBXrb_8K=pyA@mail.gmail.com>
 <CAPpHfdtsGSywUExfKMakAuRz8-+61d-4XHkVf=pNQeYTZTVYoA@mail.gmail.com>
 <CAMtXxw8J7L0r8aXt9NBFfqqSnaNyU=-_Uq4tW4aO3PHyVeXLAQ@mail.gmail.com>
 <CAPpHfdvLCgXgdhSvuPCkek+r=P4E-WiNceWfh7UQztiMzfFcvg@mail.gmail.com>
 <aegLPbRmc95UbOZG@paquier.xyz>
 <CAPpHfdsOkkeobCfO9hJvaE2fRcdGmWJoX0umx--DnApmtmefCg@mail.gmail.com>
In-Reply-To: 
 <CAPpHfdsOkkeobCfO9hJvaE2fRcdGmWJoX0umx--DnApmtmefCg@mail.gmail.com>
From: Daniil Davydov <3danissimo@gmail.com>
Date: Sat, 2 May 2026 22:37:35 +0700
Message-ID: 
 <CAJDiXgjNySH7Od3nZGjWy30sKv+-12c=kajL7Qfkj3y+CDRwtA@mail.gmail.com>
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
 Soumya S Murali <soumyamurali.work@gmail.com>,
	Jim Jones <jim.jones@uni-muenster.de>, Tom Lane <tgl@sss.pgh.pa.us>,
	Stepan Neretin <slpmcf@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	Mohamed Ali <moali.pg@gmail.com>, Nazneen Jafri <jafrinazneen@gmail.com>,
	Shawn McCoy <shawn.the.mccoy@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJDiXgjNySH7Od3nZGjWy30sKv%2B-12c%3DkajL7Qfkj3y%2BCDRwtA%40mail.gmail.com>
Precedence: bulk

Hi,

On Sat, May 2, 2026 at 9:16=E2=80=AFPM Alexander Korotkov <aekorotkov@gmail=
.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..

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 acces=
s
> 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.

--
Best regards,
Daniil Davydov