Re: Forbid to DROP temp tables of other sessions

From: Rafia Sabih <rafia(dot)pghackers(at)gmail(dot)com>
To: Daniil Davydov <3danissimo(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Forbid to DROP temp tables of other sessions
Date: 2024-10-30 12:32:32
Message-ID: CA+FpmFdYGuN21_5o9BK40NQZ5+GND+9GMuOpPeqk2StFVzxhHQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 29 Oct 2024 at 07:22, Daniil Davydov <3danissimo(at)gmail(dot)com> wrote:

> Hi,
> Thanks for your comments, I appreciate them.
>
> As I continued to deal with the topic of working with temp tables of
> other sessions, I noticed something like a bug. For example
> (REL_17_STABLE):
> Session 1:
> =# CREATE TEMP TABLE test(id int);
>
> Session 2:
> =# INSERT INTO pg_temp_0.test VALUES (1);
> =# INSERT INTO pg_temp_0.test VALUES (2);
>
> Second INSERT command will end with an error "cannot access temporary
> tables of other sessions". I checked why this is happening and found
> errors in several places.
>

Good catch. I agree with this being an unwarranted behaviour.
A minor comment from my end is the wording of the error message.
Based on the Postgresql error message style huide, something like this
could be better,
"could not access temporary relations of other sessions".

> So, I attach two files to this email :
> 1) Isolation test, that shows an error in REL_17_STABLE (iso_1.patch)
> 2) Patch that fixes code that mistakenly considered temporary tables
> to be permanent (I will be glad to receive feedback on these fixes) +
> isolation test, which shows that now any action with temp table of
> other session leads to error (temp_tbl_fix.patch)
>
> Tests look kinda ugly, but I think it's inevitable, given that we
> don't know exactly what the name of the temporary schema of other
> session will be.
>
> --
> Best regards,
> Daniil Davydov
>

--
Regards,
Rafia Sabih
CYBERTEC PostgreSQL International GmbH

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Junwang Zhao 2024-10-30 12:36:25 Re: Wrong result when enable_partitionwise_join is on if collation of PartitionKey and Column is different.
Previous Message jian he 2024-10-30 12:31:36 Re: doc issues in event-trigger-matrix.html