Re: Fix bug with accessing to temporary tables of other sessions

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