Re: Logical replication - schema change not invalidating the relation cache

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Logical replication - schema change not invalidating the relation cache
Date: 2021-07-03 05:53:06
Message-ID: CAFiTN-t7HYGft-TnpiwsNcp+TF_vrB+3nDuNjSoM02R0VY733Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 2, 2021 at 12:03 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> Yeah, this looks like a bug. I will look at the patch.
>

While looking into this, I think the main cause of the problem is that
schema rename does not invalidate the relation cache right? I also
tried other cases e.g. if there is an open cursor and we rename the
schema

CREATE SCHEMA sch1;
CREATE TABLE sch1.t1(c1 int);
insert into sch1.t1 values(1);
insert into sch1.t1 values(2);
insert into sch1.t1 values(3);
BEGIN;
DECLARE mycur CURSOR FOR SELECT * FROM sch1.t1;
FETCH NEXT FROM mycur ;
----------At this point rename sch1 to sch2 from another session------
FETCH NEXT FROM mycur ;
UPDATE sch2.t1 SET c1 = 20 WHERE CURRENT OF mycur;
select * from sch2.t1 ;

So even after the schema rename the cursor is able to fetch and its
also able to update on the same table in the new schema, ideally using
CURRENT OF CUR, you can update the same table for which you have
declared the cursor. I am giving this example because this behavior
also looks somewhat similar.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2021-07-03 07:06:06 Re: rand48 replacement
Previous Message Bharath Rupireddy 2021-07-03 04:43:22 Re: logical replication worker accesses catalogs in error context callback