RE: Handle infinite recursion in logical replication setup

Hi Vegnesh,

While considering about second problem, I was very confusing about it.
I'm happy if you answer my question.

> To handle this if user has specified only_local option, we could throw
> a warning or error out while creating subscription in this case, we
> could have a column srreplicateddata in pg_subscription_rel which
> could indicate if the table has any replicated data or not:
> postgres=# select * from pg_subscription_rel;
> srsubid | srrelid | srsubstate | srsublsn | srreplicateddata
> ---------+---------+------------+-----------+------------------
> 16389 | 16384 | r | 0/14A4640 | t
> 16389 | 16385 | r | 0/14A4690 | f
> (1 row)
> In the above example, srreplicateddata with true indicates, tabel t1
> whose relid is 16384 has replicated data and the other row having
> srreplicateddata as false indicates table t2 whose relid is 16385
> does not have replicated data.
> When creating a new subscription, the subscriber will connect to the
> publisher and check if the relation has replicated data by checking
> srreplicateddata in pg_subscription_rel table.
> If the table has any replicated data, log a warning or error for this.

IIUC srreplicateddata represents whether the subscribed data is not
generated from the publisher, but another node.
My first impression was that the name 'srreplicateddata' is not friendly
because all subscribed data is replicated from publisher.
Also I was not sure how value of the column was set.
IIUC a filtering by replication origins is done in publisher node
and subscriber node cannot know
whether some data are really filtered or not.
If we distinguish by subscriber option publish_local_only,
it cannot reproduce your example because same subscriber have different 'srreplicateddata'.

Best Regards,
Hayato Kuroda
FUJITSU LIMITED