Message-ID: <67637cf8-8cbf-4f86-8775-52aa0329972d@uni-muenster.de>
Date: Wed, 8 Apr 2026 12:41:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Soumya S Murali <soumyamurali.work@gmail.com>,
 Daniil Davydov <3danissimo@gmail.com>
Cc: 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>
 <2f3fa419-9000-4e2a-b070-6e35d5de0e4c@uni-muenster.de>
 <CAJDiXgghbz2TL1b5HbvB7pQzM6S4QDxcuLP-tyOzj1tZunvXJA@mail.gmail.com>
 <751a6cb8-cac8-46c4-8c64-9e23f663e926@uni-muenster.de>
 <CAJDiXgiMg_f0A1aESQrwFzeAkUieXBy8vFq_zisvTKQcGQJcCg@mail.gmail.com>
 <CAJDiXgj5rFYxuLYSpQxidQ+1cZ=6rJx29MvV+RAjKX7B=EGUvw@mail.gmail.com>
 <CAJDiXggOEN06RwBBCJ-egzkmTbm81=LJ5eCNmvzr=Bpwnp5VzA@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>
Content-Language: de-DE, en-GB
From: Jim Jones <jim.jones@uni-muenster.de>
In-Reply-To: 
 <CAMtXxw8pHLH9+mG3wxsF8f=Y+pHqTNP8X1UmZQPkRL9pZ5aF2w@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/67637cf8-8cbf-4f86-8775-52aa0329972d%40uni-muenster.de>
Precedence: bulk

Hi

On 08/04/2026 11:17, Soumya S Murali wrote:
> I worked on the issue of accessing temporary tables belonging to other
> sessions and tried implementing the fix at the buffer manager level,
> as suggested. I added checks in ReadBuffer_common() and
> PrefetchBuffer() to reject access when a relation is temporary
> (relpersistence = TEMP) but does not use local buffers
> (!RelationUsesLocalBuffers) so that it ensures only heap page access
> is blocked, while catalog lookups and other metadata operations
> continue to work as before. While testing, I observed that in many
> cases the query does not reach the buffer manager because name
> resolution fails earlier with “relation does not exist”. However, the
> added checks ensure that even if execution reaches the buffer layer,
> access to other sessions’ temporary tables is safely rejected. The
> change is minimal, and did not modify parser/ACL behavior and all
> regression tests got passed successfully too.
> Kindly review the attached patch herewith. Please let me know if this
> approach aligns with expectations or if further adjustments are
> needed.

A few comments:

== PrefetchBuffer ==

The condition nested inside the if (RelationUsesLocalBuffers(reln))
tests the opposite of the main if !RelationUsesLocalBuffers(reln):

if (RelationUsesLocalBuffers(reln))
{
  /* ACCESS DENIED CHECK */
  if (reln != NULL &&
  reln->rd_rel != NULL &&
  reln->rd_rel->relpersistence == RELPERSISTENCE_TEMP &&
  !RelationUsesLocalBuffers(reln))
  {
  ereport(ERROR,
  	(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
  	errmsg("cannot access temporary tables of other sessions")));
  }
...
}

So it'll be always false, making the ereport unreachable.

== ReadBufferExtended ==

These conditions cancel each other out:

if (reln->rd_rel->relpersistence == RELPERSISTENCE_TEMP &&
    !RelationUsesLocalBuffers(reln))

RelationUsesLocalBuffers(reln) expands to
((relation)->rd_rel->relpersistence == RELPERSISTENCE_TEMP), making the
error message unreachable. Perhaps you meant RELATION_IS_OTHER_TEMP?

== ReadBuffer_common ==

Same as in ReadBufferExtended and PrefetchBuffer.

== tests ==

You excluded the tests from the patch.

== patch version ==

You forgot to add the patch version.

Best, Jim