Repeatable read transaction doesn't see dropped table - Mailing list pgsql-hackers

From Daniil Davydov
Subject Repeatable read transaction doesn't see dropped table
Date
Msg-id CAJDiXgheb2G_OPUfvRt9g9QYFbjn0d4Jx6unk2W_RUorJ=W3ig@mail.gmail.com
Whole thread Raw
Responses Re: Repeatable read transaction doesn't see dropped table
List pgsql-hackers
Hi,
The documentation for PostgreSQL 17 says the following :
"query in a repeatable read transaction sees a snapshot as of the
start of the first non-transaction-control statement in the
transaction, not as of the start of the current statement within the
transaction"

But I noticed this behavior (REL_17_STABLE):
***
SESSION 1: create two user tables and fill them with data
CREATE TABLE test (id INT);
CREATE TABLE test_1 (id INT);
INSERT INTO test VALUES (1);
INSERT INTO test_1 VALUES (1);

SESSION 2 : begin transaction and allow it to take snapshot
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT * FROM test_1;

SESSION 1 : drop table, that was not accessed from second session
DROP TABLE test;

SESSION 2 :
SELECT * FROM test;
***

If I'm not mistaken, second transaction must see all data in table
test (according to documentation), but an error occurs:
***
ERROR:  relation "test" does not exist
LINE 1: select * from test;
***

We are getting this behavior due to the fact that the second session
searching for table's oid in cache via RelnameGetRelid,
but first session already invalidated it. It seems like a bug to me,
so I suggest in such cases to additionally scan pg_class.

I would like to know your opinion.

--
Best regards,
Daniil Davydov



pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Logical Replication of sequences
Next
From: "David G. Johnston"
Date:
Subject: Re: Repeatable read transaction doesn't see dropped table