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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Logical replication - schema change not invalidating the relation cache
Date: 2023-01-05 23:02:31
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

vignesh C <vignesh21(at)gmail(dot)com> writes:
> On Thu, 5 Jan 2023 at 03:17, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> The bigger picture here though is that in examples such as the one
>> you gave at the top of the thread, it's not very clear to me that
>> there's *any* principled behavior. If the connection between publisher
>> and subscriber tables is only the relation name, fine ... but exactly
>> which relation name applies?

> The connection between publisher and subscriber table is based on
> relation id, During the first change relid, relname and schema name
> from publisher will be sent to the subscriber. Subscriber stores these
> id, relname and schema name in the LogicalRepRelMap hash for which
> relation id is the key. Subsequent data received in the subscriber
> will use the relation id received from the publisher and apply the
> changes in the subscriber.

Hm. I spent some time cleaning up this patch, and found that there's
still a problem. ISTM that the row with value "3" ought to end up
in the subscriber's sch2.t1 table, but it does not: the attached
test script fails with

t/ .. 6/?
# Failed test 'check data in subscriber sch2.t1 after schema rename'
# at t/ line 361.
# got: ''
# expected: '3'
# Looks like you failed 1 test of 9.
t/ .. Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/9 subtests

What's up with that?

regards, tom lane

Attachment Content-Type Size
v5-0001-Fix-for-invalidating-logical-replication-relation.patch text/x-diff 5.3 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alex Fan 2023-01-05 23:19:55 Re: [PATCH] Enable using llvm jitlink as an alternative llvm jit linker of old Rtdyld.
Previous Message Tom Lane 2023-01-05 21:56:55 Re: postgres_fdw: using TABLESAMPLE to collect remote sample