Re: Logical replication - schema change not invalidating the relation cache - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Logical replication - schema change not invalidating the relation cache
Date
Msg-id CAFiTN-sqPxGwfC7+PsDKZUd9O9R5EevWF-sPE2EJj=doPndRyw@mail.gmail.com
Whole thread Raw
In response to Logical replication - schema change not invalidating the relation cache  (vignesh C <vignesh21@gmail.com>)
Responses Re: Logical replication - schema change not invalidating the relation cache
List pgsql-hackers
On Fri, Jul 2, 2021 at 11:11 AM vignesh C <vignesh21@gmail.com> wrote:
>
> Hi,
>
> I found a strange behavior when there is an insert after renaming the
> schema. The test steps for the same are given below, Here after the
> schema is renamed, the renamed schema table data should not be sent,
> but the data was being sent. I felt the schema invalidation was not
> called, attached a patch to handle the same. Thoughts?
>
> step 1)
> Create schema sch1;
> Create table sch1.t1(c1 int);
> CREATE PUBLICATION mypub1 FOR all tables;
>
> Step 2)
> CREATE SCHEMA sch1;
> CREATE TABLE sch1.t1(c1 int);
> CREATE SCHEMA sch2;
> CREATE TABLE sch2.t1(c1 int);
> CREATE TABLE t1(c1 int);
> CREATE SUBSCRIPTION mysub1 CONNECTION 'host=localhost port=5432
> dbname=postgres' PUBLICATION mypub1;
>
> Step 3)
> begin;
> insert into sch1.t1 values(1);
> alter schema sch1 rename to sch2;
> create schema sch1;
> create table sch1.t1(c1 int);
> insert into sch1.t1 values(2);
> insert into sch2.t1 values(3);
> commit;
>
> step 4)
> select * from sch1.t1; # In subscriber
> Got:
> c1
> ----
>   1
>   2
>   3
> (3 rows)
>
> Expected:
> c1
> ----
>   1
>   2
> (2 rows)

Yeah, this looks like a bug.  I will look at the patch.

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



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Can a child process detect postmaster death when in pg_usleep?
Next
From: Andrey Borodin
Date:
Subject: Re: Synchronous commit behavior during network outage