RE: Per-table resync for logical replication subscriptions - Mailing list pgsql-hackers

From Hayato Kuroda (Fujitsu)
Subject RE: Per-table resync for logical replication subscriptions
Date
Msg-id OS9PR01MB183223EA861055F43E1A350FEF5802@OS9PR01MB18322.jpnprd01.prod.outlook.com
Whole thread
In response to RE: Per-table resync for logical replication subscriptions  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
List pgsql-hackers
Dear Cagri,

While thinking this feature again, I had two points:

01.
Assuming the below schema definition, which only the subscriber has a partition:

```
pub - sub
tab   tab
       - tab_part1 // stores data from pub
       - tab_part2 // stores data generated locally
```

In this case, REFRESH TABLE tab command truncate partition leaves. Data in
tab_part1 could be re-synced but tuples in tab_part2 were gone. Is it OK?

I felt several issues have been reported for the partition table, and this trend
would continue. How about separating the patch into two parts, 0001 is for normal
tables (reject for partition root) and 0002 adds the partition handling?

02.
Logical replication allowed to construct two(three)-way replication with the
subscription parameter origin=none. Can you evaluate the combination? I'm worry
because initial sync does not take care the origin of tuples.

Best regards,
Hayato Kuroda
FUJITSU LIMITED

pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation
Next
From: Nisha Moond
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication