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

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