Message-ID: <98c1c0d9-7962-4669-90f2-deb28a665a55@uni-muenster.de>
Date: Sat, 25 Apr 2026 00:09:39 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Fix bug with accessing to temporary tables of other sessions
To: Michael Paquier <michael@paquier.xyz>,
 Alexander Korotkov <aekorotkov@gmail.com>
Cc: Soumya S Murali <soumyamurali.work@gmail.com>,
 Daniil Davydov <3danissimo@gmail.com>, 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>
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>
Content-Language: de-DE, en-GB
From: Jim Jones <jim.jones@uni-muenster.de>
In-Reply-To: <aegLPbRmc95UbOZG@paquier.xyz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/98c1c0d9-7962-4669-90f2-deb28a665a55%40uni-muenster.de>
Precedence: bulk

Hi Michael,

Thanks for the review.

On 22/04/2026 01:41, Michael Paquier wrote:
> As a whole, we were not really convinced that this is something that
> needs any kind of specific fix, especially not something that should
> be backpatched.

This surprises me a little bit. Until now I was under the impression
that fixing it was the consensus here. Just the "how" was being discussed.

> After saying all that, there is some value in what you are doing here:
> it is true that we lack test coverage in terms of interactions of
> temporary objects across multiple sessions, and that we should have
> some.  TAP is adapted for this purpose, isolation tests could be an
> extra one but the schema names make that unpredictible in output.  The
> patch unfortunately does a poor job in showing what it wants to
> change.  One thing that I would suggest is to *reverse* the order of
> the patches:
> - First have a patch that introduces new tests, that shows the
> original behavior.  This needs to be more complete in terms of command
> patterns.  The DROP TABLE is one case that we want to keep.  This
> should be kept as-is, and it is critical to document the reason why we
> want to keep things this way (aka autovacuum and orphaned tables,
> AFAIK).
> - Then implement the second patch that updates the tests introduced in
> the first patch, so as one can track *what* has changed, and so as one
> does not have to test manually what the original behavior was.


Fair point on tests comments and coverage. But before we start with the
refactoring, I'd like to make sure I understood your suggestion
correctly. You're suggesting:

0001 - TAP tests with improved coverage and comments that pass on
current master, documenting the existing behaviour, which means broken
commands silently succeed (e.g. SELECT returns 0 rows, no error)

0002 - read_stream.c and bufmgr.c fix + updated test expectations (the
same commands now raise errors)

Is it what you had in mind?

Best, Jim