Hi, On Thu, May 14, 2026 at 8:39 PM Alexander Korotkov <[email protected]> wrote: > > On Thu, May 14, 2026 at 9:58 AM Michael Paquier <[email protected]> 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 <[email protected]> > > > 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
