Thread

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

   Jim Jones <jim.jones@uni-muenster.de> — 2026-05-01T19:16:39Z

   Hi
   
   On 25/04/2026 10:34, Daniil Davydov wrote:
   > On Wed, Apr 22, 2026 at 6:41 AM Michael Paquier <michael@paquier.xyz> wrote:
   >>
   >> On Tue, Apr 21, 2026 at 01:54:47PM +0300, Alexander Korotkov wrote:
   >>> OK. I'm going to push and backpatch if no objections.
   >>
   >> As a whole, we were not really convinced that this is something that
   >> needs any kind of specific fix
   > 
   > It is a bug, obviously. TBH, I don't see any reason for not fixing it.
   > 
   >> especially not something that should
   >> be backpatched.
   
   
   I see there are differing opinions among committers on this. How should
   we proceed? Do we really consider the current behaviour acceptable, or
   should we invest effort in improving the tests (and potentially
   backpatch it)?
   
   Best, Jim
   
   
   
   
   

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

   Alexander Korotkov <aekorotkov@gmail.com> — 2026-05-02T14:16:39Z

   Hi, Michael!
   
   On Wed, Apr 22, 2026 at 2:41 AM Michael Paquier <michael@paquier.xyz> wrote:
   >
   > On Tue, Apr 21, 2026 at 01:54:47PM +0300, Alexander Korotkov wrote:
   > > OK. I'm going to push and backpatch if no objections.
   >
   > Timing is interesting here.  Last week I have been doing a on-site
   > patch review with a couple of colleagues and myself, and this thread
   > has been chosen as part of this exercise.  I am attaching them in CC
   > of this thread, and replying to this thread was an action item I had
   > to act on.
   >
   > Here is some feedback, based on v18 posted here:
   > https://www.postgresql.org/message-id/b6614954-6c71-451a-a1d7-345d255b4afb@uni-muenster.de
   >
   > We have found that the thread does not state clearly what it aims to
   > fix.  The subject states that it is a bug, perhaps it is but the
   > thread does not seem to do a good job in explaining why the current
   > superuser behavior is bad, while the behavior of the patch to block
   > some commands is better.  This should be clearer in explaining why
   > this new behavior is better.
   >
   > The test script is under-documented.  There are zero comments that
   > actually explain why the patch does what it does.  The few comments
   > present could be removed: they are copy-pasted of the descriptions of
   > the test cases.  A much worse thing is this thing:
   >
   > +# DROP TEMPORARY TABLE from other session
   > +$node->safe_psql('postgres', "DROP TABLE $tempschema.foo;");
   >
   > DROP TABLE on a temporary relation for a superuser is a very useful
   > behavior to unstuck autovacuum if a temp relation has been orphaned.
   > It looks critical to me to explain that we want to keep this behavior
   > for this reason.  Using safe_psql() is not really adapted.  You should
   > use a psql() where we check that the command does not fail, so as the
   > test can generate a full report.
   >
   > The test coverage actually has holes.  The three DML patterns INSERT,
   > UPDATE and DELETE are covered, and it is missing MERGE.  Also, what
   > about other patterns like ALTER TABLE, ALTER INDEX, ALTER FUNCTION,
   > DROP FUNCTION and the like?  There are many object patterns that can
   > be schema-qualified, and none of this is covered.  What about the new
   > REPACK and a bunch of other maintenance commands?  There is nothing
   > about VACUUM, TRUNCATE, CLUSTER, etc.  Just to name a few.
   >
   > Another question is how do we make sure that new command patterns
   > follow the same rule as what is enforced here.  It looks like this
   > should be at least documented somewhere to be less surprising, but the
   > patch does nothing of the kind.
   >
   > As a whole the patch lacks documentation, comments, and explanations,
   > making it difficult to act on.
   >
   > 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.
   >
   > 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.
   >
   > As a whole, this patch needs more work, based on what has been
   > currently posted on the lists.  That's not ready yet.  The backpatch
   > question is a separate matter.
   
   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.
   
   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.
   
   Links.
   1. https://www.postgresql.org/message-id/3529398.1774273446%40sss.pgh.pa.us
   
   ------
   Regards,
   Alexander Korotkov
   Supabase
   
   
   
   

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

   Daniil Davydov <3danissimo@gmail.com> — 2026-05-02T15:37:35Z

   Hi,
   
   On Sat, May 2, 2026 at 9:16 PM 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 access
   > 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
   
   
   
   

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

   Alexander Korotkov <aekorotkov@gmail.com> — 2026-05-02T16:34:00Z

   On Sat, May 2, 2026 at 6:37 PM Daniil Davydov <3danissimo@gmail.com> wrote:
   > On Sat, May 2, 2026 at 9:16 PM 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..
   
   Here they are.
   
   > 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 access
   > > 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.
   
   This is possible, but I would keep that in a separate patch.  We now
   have clear scope for both patches: 0001 includes additional tests,
   0002 fixes the bug and restores old behavior.
   
   ------
   Regards,
   Alexander Korotkov
   Supabase
   

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

   Jim Jones <jim.jones@uni-muenster.de> — 2026-05-02T17:32:30Z

   Hi
   
   On 02/05/2026 18:34, Alexander Korotkov wrote:
   > On Sat, May 2, 2026 at 6:37 PM Daniil Davydov <3danissimo@gmail.com> wrote:
   >> On Sat, May 2, 2026 at 9:16 PM 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.
   
   +1
   
   >>> 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..
   > 
   > Here they are.
   
   
   Thanks for the comprehensive additional tests!
   
   In addition to the DROP TABLE exception:
   
   It is also possible to LOCK temporary tables from other sessions:
   
   postgres=# BEGIN;
   BEGIN
   postgres=*# LOCK TABLE pg_temp_91.t IN ACCESS SHARE MODE ;
   LOCK TABLE
   
   pg_temp_91.t lives as long the transaction is open -- even after the
   origin session closes, which is totally expected. I'd say it falls into
   the same category of DROP TABLE, where the table contents are never
   read, so I'd argue it's ok.
   
   > 
   >> 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 access
   >>> 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.
   > 
   > This is possible, but I would keep that in a separate patch.  We now
   > have clear scope for both patches: 0001 includes additional tests,
   > 0002 fixes the bug and restores old behavior.
   
   +1 for a separate patch. I think the scope of the current patch is good
   as-is.
   
   Thanks!
   
   Best, Jim
   
   
   
   
   
   

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

   Daniil Davydov <3danissimo@gmail.com> — 2026-05-03T08:53:39Z

   Hi,
   
   On Sun, May 3, 2026 at 12:32 AM Jim Jones <jim.jones@uni-muenster.de> wrote:
   >
   > In addition to the DROP TABLE exception:
   >
   > It is also possible to LOCK temporary tables from other sessions:
   >
   > postgres=# BEGIN;
   > BEGIN
   > postgres=*# LOCK TABLE pg_temp_91.t IN ACCESS SHARE MODE ;
   > LOCK TABLE
   >
   > pg_temp_91.t lives as long the transaction is open -- even after the
   > origin session closes, which is totally expected. I'd say it falls into
   > the same category of DROP TABLE, where the table contents are never
   > read, so I'd argue it's ok.
   
   Autovacuum locks orphaned table's oid before deleting it. LOCK TABLE command
   also locks the oid of the specified table. If we want to make sure that
   autovacuum can acquire the mentioned lock (i.e. cover this behavior using
   tests), I suggest testing it using the LOCK TABLE command.
   
   Please, see the attached patch that ensures that cross-session LOCK TABLE works
   properly.
   
   --
   Best regards,
   Daniil Davydov
   

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

   Jim Jones <jim.jones@uni-muenster.de> — 2026-05-03T12:49:03Z

   Hi Daniil
   
   On 03/05/2026 10:53, Daniil Davydov wrote:
   > Autovacuum locks orphaned table's oid before deleting it. LOCK TABLE command
   > also locks the oid of the specified table. If we want to make sure that
   > autovacuum can acquire the mentioned lock (i.e. cover this behavior using
   > tests), I suggest testing it using the LOCK TABLE command.
   
   +1 for the extra test.
   
   > Please, see the attached patch that ensures that cross-session LOCK TABLE works
   > properly.
   
   I guess you should either add it to the 0001 sent by Alexander, or 
   create a 0003. Right now the cfbot is complaining, as 
   013_temp_obj_multisession.pl still does not exist :)
   
   Best, Jim
   
   
   
   

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

   Daniil Davydov <3danissimo@gmail.com> — 2026-05-04T09:31:18Z

   Hi,
   
   On Sun, May 3, 2026 at 7:49 PM Jim Jones <jim.jones@uni-muenster.de> wrote:
   >
   > On 03/05/2026 10:53, Daniil Davydov wrote:
   > > Please, see the attached patch that ensures that cross-session LOCK TABLE works
   > > properly.
   >
   > I guess you should either add it to the 0001 sent by Alexander, or
   > create a 0003. Right now the cfbot is complaining, as
   > 013_temp_obj_multisession.pl still does not exist :)
   >
   
   OK, I'll attach this patch as a third one, just for review purposes. After
   agreement on its content, it should be included into the 0001 and 0002 patches.
   
   --
   Best regards,
   Daniil Davydov
   

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

   Alexander Korotkov <aekorotkov@gmail.com> — 2026-05-07T08:04:16Z

   On Mon, May 4, 2026 at 12:31 PM Daniil Davydov <3danissimo@gmail.com> wrote:
   >
   > On Sun, May 3, 2026 at 7:49 PM Jim Jones <jim.jones@uni-muenster.de> wrote:
   > >
   > > On 03/05/2026 10:53, Daniil Davydov wrote:
   > > > Please, see the attached patch that ensures that cross-session LOCK TABLE works
   > > > properly.
   > >
   > > I guess you should either add it to the 0001 sent by Alexander, or
   > > create a 0003. Right now the cfbot is complaining, as
   > > 013_temp_obj_multisession.pl still does not exist :)
   > >
   >
   > OK, I'll attach this patch as a third one, just for review purposes. After
   > agreement on its content, it should be included into the 0001 and 0002 patches.
   
   Thank you.  I've integrated your check into 0001, and added an
   explicit check that the table gets removed once the lock by other
   session is removed.
   
   Let me do a quick summary:
    * Our buffer manager is not capable for reading temp tables of other sessions.
    * This was covered by explicit checks, but broken since b7b0f3f27241
   introduced alternative code path for reading tables.
    * This doesn't apply to DROP TABLE.  DROP TABLE is a conscious
   exclusion and the only operation we can do correctly for other
   session' temp tables.  There is an explicit exclusion in the code to
   skip the attempt to cleanup buffers of other session' temp tables.
    * This patchset consists of tests (0001) for various operations with
   other session's temp tables including buggy behavior, and the fix
   (0002) including changes for tests.
   
   Thus, I don't see the reason why this shouldn't be committed and
   backpatched to PG17 (first release containing b7b0f3f27241).
   Opinions?  Michael?
   
   ------
   Regards,
   Alexander Korotkov
   Supabase
   

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

    Jim Jones <jim.jones@uni-muenster.de> — 2026-05-07T08:43:01Z

    On 07/05/2026 10:04, Alexander Korotkov wrote:
    > Thus, I don't see the reason why this shouldn't be committed and
    > backpatched to PG17 (first release containing b7b0f3f27241).
    
    Quick question: should we work on a separate patch for PG14-PG16? In 
    these versions, the error message is raised depending on the temporary 
    table's tuple count, as demonstrated in [1]:
    
    == session 1 ==
    
    psql (14.20 (Debian 14.20-1.pgdg13+1))
    Type "help" for help.
    
    postgres=# CREATE TEMPORARY TABLE t (id int);
    CREATE TABLE
    postgres=# \d pg_temp*.*
                     Table "pg_temp_3.t"
      Column |  Type   | Collation | Nullable | Default
    --------+---------+-----------+----------+---------
      id     | integer |           |          |
    
    == session 2 ==
    
    psql (14.20 (Debian 14.20-1.pgdg13+1))
    Type "help" for help.
    
    postgres=# SELECT * FROM pg_temp_3.t;
      id
    ----
    (0 rows)
    
    == session 1 ==
    
    postgres=# INSERT INTO t VALUES (42);
    INSERT 0 1
    
    == session 2 ==
    
    postgres=# SELECT * FROM pg_temp_3.t;
    ERROR:  cannot access temporary tables of other sessions
    
    Thanks!
    
    Best, Jim
    
    1 - 
    https://www.postgresql.org/message-id/800c75af-9bd0-48ac-b4bf-54cadf2bc723%40uni-muenster.de
    
    
    
    
    

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

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-05-07T10:43:40Z

    On Thu, May 7, 2026 at 11:43 AM Jim Jones <jim.jones@uni-muenster.de> wrote:
    > On 07/05/2026 10:04, Alexander Korotkov wrote:
    > > Thus, I don't see the reason why this shouldn't be committed and
    > > backpatched to PG17 (first release containing b7b0f3f27241).
    >
    > Quick question: should we work on a separate patch for PG14-PG16? In
    > these versions, the error message is raised depending on the temporary
    > table's tuple count, as demonstrated in [1]:
    >
    > == session 1 ==
    >
    > psql (14.20 (Debian 14.20-1.pgdg13+1))
    > Type "help" for help.
    >
    > postgres=# CREATE TEMPORARY TABLE t (id int);
    > CREATE TABLE
    > postgres=# \d pg_temp*.*
    >                  Table "pg_temp_3.t"
    >   Column |  Type   | Collation | Nullable | Default
    > --------+---------+-----------+----------+---------
    >   id     | integer |           |          |
    >
    > == session 2 ==
    >
    > psql (14.20 (Debian 14.20-1.pgdg13+1))
    > Type "help" for help.
    >
    > postgres=# SELECT * FROM pg_temp_3.t;
    >   id
    > ----
    > (0 rows)
    >
    > == session 1 ==
    >
    > postgres=# INSERT INTO t VALUES (42);
    > INSERT 0 1
    >
    > == session 2 ==
    >
    > postgres=# SELECT * FROM pg_temp_3.t;
    > ERROR:  cannot access temporary tables of other sessions
    
    Thank you for your question.  Yes, PostgreSQL 14-16 first does
    RelationGetNumberOfBlocks(), then scans the relation through the
    buffer manager.  If RelationGetNumberOfBlocks() returns 0, then no
    buffers accessed and no error thrown.  So, it could scan empty tables
    because it doesn't requires accessing local buffers of other sessions.
    I would investigate this further.  If this doesn't have negative side
    effects (like execution of other commands that couldn't be performed
    correctly), I would avoid backpatching to these versions.
    
    ------
    Regards,
    Alexander Korotkov
    Supabase
    
    
    
    

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-07T14:22:44Z

    Alexander Korotkov <aekorotkov@gmail.com> writes:
    > Thus, I don't see the reason why this shouldn't be committed and
    > backpatched to PG17 (first release containing b7b0f3f27241).
    
    We are less than 48 hours from code freeze for this month's back
    branch releases.  I think it's already too late for any inessential
    changes, especially if you're less than 100.00% sure of them.
    Please hold off until after the release cycle.
    
    			regards, tom lane
    
    
    
    

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

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-05-07T16:13:33Z

    Hi, Tom!
    
    On Thu, May 7, 2026 at 5:22 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
    > Alexander Korotkov <aekorotkov@gmail.com> writes:
    > > Thus, I don't see the reason why this shouldn't be committed and
    > > backpatched to PG17 (first release containing b7b0f3f27241).
    >
    > We are less than 48 hours from code freeze for this month's back
    > branch releases.  I think it's already too late for any inessential
    > changes, especially if you're less than 100.00% sure of them.
    > Please hold off until after the release cycle.
    
    Thank you for noticing.  Yes, I'm not 100% sure new tap tests wouldn't
    break buildfarm.  It would be pity to break it so close to the release
    freeze.  I'll wait.
    
    ------
    Regards,
    Alexander Korotkov
    Supabase
    
    
    
    

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

    Michael Paquier <michael@paquier.xyz> — 2026-05-08T06:19:32Z

    On Thu, May 07, 2026 at 11:04:16AM +0300, Alexander Korotkov wrote:
    > Let me do a quick summary:
    >  * Our buffer manager is not capable for reading temp tables of other sessions.
    >  * This was covered by explicit checks, but broken since b7b0f3f27241
    > introduced alternative code path for reading tables.
    >  * This doesn't apply to DROP TABLE.  DROP TABLE is a conscious
    > exclusion and the only operation we can do correctly for other
    > session' temp tables.  There is an explicit exclusion in the code to
    > skip the attempt to cleanup buffers of other session' temp tables.
    >  * This patchset consists of tests (0001) for various operations with
    > other session's temp tables including buggy behavior, and the fix
    > (0002) including changes for tests.
    > 
    > Thus, I don't see the reason why this shouldn't be committed and
    > backpatched to PG17 (first release containing b7b0f3f27241).
    > Opinions?  Michael?
    
    Hmm.  I don't have any counter-arguments against a backpatch based on
    your argument related to b7b0f3f27241.  Thanks for reorganizing the
    patch set so as the tests happen first, and the changes in the code
    become second.
    
    If you wish me to look at this patch set in details, I may be able to
    do so around the beginning of next week.  I'm not sure that there is a
    strong urgency in tackling this issue for this minor release, this
    could wait a bit more..
    --
    Michael
    

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

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-05-08T06:39:09Z

    On Fri, May 8, 2026 at 9:19 AM Michael Paquier <michael@paquier.xyz> wrote:
    > On Thu, May 07, 2026 at 11:04:16AM +0300, Alexander Korotkov wrote:
    > > Let me do a quick summary:
    > >  * Our buffer manager is not capable for reading temp tables of other sessions.
    > >  * This was covered by explicit checks, but broken since b7b0f3f27241
    > > introduced alternative code path for reading tables.
    > >  * This doesn't apply to DROP TABLE.  DROP TABLE is a conscious
    > > exclusion and the only operation we can do correctly for other
    > > session' temp tables.  There is an explicit exclusion in the code to
    > > skip the attempt to cleanup buffers of other session' temp tables.
    > >  * This patchset consists of tests (0001) for various operations with
    > > other session's temp tables including buggy behavior, and the fix
    > > (0002) including changes for tests.
    > >
    > > Thus, I don't see the reason why this shouldn't be committed and
    > > backpatched to PG17 (first release containing b7b0f3f27241).
    > > Opinions?  Michael?
    >
    > Hmm.  I don't have any counter-arguments against a backpatch based on
    > your argument related to b7b0f3f27241.  Thanks for reorganizing the
    > patch set so as the tests happen first, and the changes in the code
    > become second.
    >
    > If you wish me to look at this patch set in details, I may be able to
    > do so around the beginning of next week.  I'm not sure that there is a
    > strong urgency in tackling this issue for this minor release, this
    > could wait a bit more..
    
    Absolutely, no urgency to include it into this minor release as I
    already agreed [1].  You're very welcome if you could take a look in
    the beginning of the next week.
    
    Links.
    1. https://www.postgresql.org/message-id/CAPpHfdsEr6RF-SkzVGD6PzFusENbpNPxKnRY7iQQ%3DcZQYJia6w%40mail.gmail.com
    
    ------
    Regards,
    Alexander Korotkov
    Supabase
    
    
    
    

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

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-05-14T06:12:58Z

    Hi, Michael!
    
    On Fri, May 8, 2026 at 9:19 AM Michael Paquier <michael@paquier.xyz> wrote:
    >
    > On Thu, May 07, 2026 at 11:04:16AM +0300, Alexander Korotkov wrote:
    > > Let me do a quick summary:
    > >  * Our buffer manager is not capable for reading temp tables of other sessions.
    > >  * This was covered by explicit checks, but broken since b7b0f3f27241
    > > introduced alternative code path for reading tables.
    > >  * This doesn't apply to DROP TABLE.  DROP TABLE is a conscious
    > > exclusion and the only operation we can do correctly for other
    > > session' temp tables.  There is an explicit exclusion in the code to
    > > skip the attempt to cleanup buffers of other session' temp tables.
    > >  * This patchset consists of tests (0001) for various operations with
    > > other session's temp tables including buggy behavior, and the fix
    > > (0002) including changes for tests.
    > >
    > > Thus, I don't see the reason why this shouldn't be committed and
    > > backpatched to PG17 (first release containing b7b0f3f27241).
    > > Opinions?  Michael?
    >
    > Hmm.  I don't have any counter-arguments against a backpatch based on
    > your argument related to b7b0f3f27241.  Thanks for reorganizing the
    > patch set so as the tests happen first, and the changes in the code
    > become second.
    >
    > If you wish me to look at this patch set in details, I may be able to
    > do so around the beginning of next week.  I'm not sure that there is a
    > strong urgency in tackling this issue for this minor release, this
    > could wait a bit more..
    
    Any news from your side?
    
    ------
    Regards,
    Alexander Korotkov
    Supabase
    
    
    
    

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

    Michael Paquier <michael@paquier.xyz> — 2026-05-14T06:58:18Z

    On Thu, May 14, 2026 at 09:12:58AM +0300, Alexander Korotkov wrote:
    > On Fri, May 8, 2026 at 9:19 AM Michael Paquier <michael@paquier.xyz> wrote:
    >> If you wish me to look at this patch set in details, I may be able to
    >> do so around the beginning of next week.  I'm not sure that there is a
    >> strong urgency in tackling this issue for this minor release, this
    >> could wait a bit more..
    > 
    > Any news from your side?
    
    (Forgot -hackers and other folks in CC, sorry about that.)
    
    Unfortunately I have not been able to get back to it this week, and
    next week is moot.  Perhaps it is better to not wait for me here, so
    feel free to go ahead as you feel. 
    --
    Michael
    

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

    Alexander Korotkov <aekorotkov@gmail.com> — 2026-05-14T13:39:04Z

    On Thu, May 14, 2026 at 9:58 AM Michael Paquier <michael@paquier.xyz> wrote:
    > On Thu, May 14, 2026 at 09:12:58AM +0300, Alexander Korotkov wrote:
    > > On Fri, May 8, 2026 at 9:19 AM Michael Paquier <michael@paquier.xyz> wrote:
    > >> If you wish me to look at this patch set in details, I may be able to
    > >> do so around the beginning of next week.  I'm not sure that there is a
    > >> strong urgency in tackling this issue for this minor release, this
    > >> could wait a bit more..
    > >
    > > Any news from your side?
    >
    > (Forgot -hackers and other folks in CC, sorry about that.)
    >
    > Unfortunately I have not been able to get back to it this week, and
    > next week is moot.  Perhaps it is better to not wait for me here, so
    > feel free to go ahead as you feel.
    
    Thank you for noticing.  I've pushed this today.  I have to slightly
    revise the tests to run on 18 and 17 (different log messages, and
    default value of log_lock_waits).
    
    ------
    Regards,
    Alexander Korotkov
    Supabase
    
    
    
    

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

    Jim Jones <jim.jones@uni-muenster.de> — 2026-05-14T16:48:47Z

    Hi Alexander
    
    On 14/05/2026 15:39, Alexander Korotkov wrote:
    > Thank you for noticing.  I've pushed this today.  I have to slightly
    > revise the tests to run on 18 and 17 (different log messages, and
    > default value of log_lock_waits).
    
    Awesome. Thanks for taking care of it!
    
    Best, Jim
    
    
    
    
    

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

    Daniil Davydov <3danissimo@gmail.com> — 2026-05-14T16:48:48Z

    Hi,
    
    On Thu, May 14, 2026 at 8:39 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
    >
    > On Thu, May 14, 2026 at 9:58 AM Michael Paquier <michael@paquier.xyz> wrote:
    > > On Thu, May 14, 2026 at 09:12:58AM +0300, Alexander Korotkov wrote:
    > > > On Fri, May 8, 2026 at 9:19 AM Michael Paquier <michael@paquier.xyz> wrote:
    > > >> If you wish me to look at this patch set in details, I may be able to
    > > >> do so around the beginning of next week.  I'm not sure that there is a
    > > >> strong urgency in tackling this issue for this minor release, this
    > > >> could wait a bit more..
    > > >
    > > > Any news from your side?
    > >
    > > (Forgot -hackers and other folks in CC, sorry about that.)
    > >
    > > Unfortunately I have not been able to get back to it this week, and
    > > next week is moot.  Perhaps it is better to not wait for me here, so
    > > feel free to go ahead as you feel.
    >
    > Thank you for noticing.  I've pushed this today.  I have to slightly
    > revise the tests to run on 18 and 17 (different log messages, and
    > default value of log_lock_waits).
    >
    
    Thank you very much for your help!)
    
    BTW, we still have another problem with temp tables. Tom wrote [1] about it
    within this thread:
    
    > Reality is that we cannot know whether an
    > unqualified-name RangeVar references a temp table until we do a
    > catalog lookup, so IMO we should not have a relpersistence field there
    > at all. At best it means something quite different from what it means
    > elsewhere, and that's a recipe for confusion. But changing that would
    > not be a bug fix (AFAIK) but refactoring to reduce the probability of
    > future bugs.
    
    I'll try to implement that next month. But if someone gets ahead of me, please
    attach me in CC of the new thread.
    
    [1] https://www.postgresql.org/message-id/4075754.1774378690%40sss.pgh.pa.us
    
    --
    Best regards,
    Daniil Davydov