> Recently I saw a report and proposed fix here [0]. I did not dig into,
just connection internets. Thanks!
Oh, I missed it. Then I'll consider my issue closed and continue discussion
in the older thread if there is something to discuss.
Thanks a lot!
--
best regards,
Mikhail A. Gribkov
e-m
> On 20 Nov 2024, at 23:35, Mikhail Gribkov wrote:
>
> Now, in the second session we will try to insert couple of rows into this
> table:
Recently I saw a report and proposed fix here [0]. I did not dig into, just
connection internets. Thanks!
Best regards, Andrey Borodin.
[0]
https://w
On Wed, Nov 20, 2024 at 5:47 PM Tom Lane wrote:
>
> Mikhail Gribkov writes:
> > What do you think?
>
> I think this will break cases we don't want to break.
>
> Accessing the metadata of other temp tables is fine, and indeed
> necessary for operations like dropping them. It's access to
> the tab
Mikhail Gribkov writes:
> What do you think?
I think this will break cases we don't want to break.
Accessing the metadata of other temp tables is fine, and indeed
necessary for operations like dropping them. It's access to
the table contents that needs to be blocked. I'm surprised
that we don'
Hi hackers,
I was experimenting with temporary tables and noticed many odd things with
them.
Short story: Having appropriate privileges, user can access other session's
temp
tables and it is a complete mess. Let's fix it.
Longer story.
Let's open two sessions for one postgres user. In the first
