Dear Shubham, Thanks for testing. It seems you ran with v20 patch, but I confirmed It could reproduce with v21.
> > I found a couple of issues, while verifying the cascaded replication > with the following scenarios: > Scenario 1) Create cascade replication like node1->node2->node3 > without using replication slots (attached > cascade_3node_setup_without_slots has the script for this): > Then I ran pg_createsubscriber by specifying primary as node1 and > standby as node3, this scenario runs successfully. I was not sure if > this should be supported or not? Hmm. After the script, the cascading would be broken. The replication would be: ``` Node1 -> node2 | Node3 ``` And the operation is bit strange. The consistent LSN is gotten from the node1, but node3 waits until it receives the record from NODE2. Can we always success it? > Scenario 2) Create cascade replication like node1->node2->node3 using > replication slots (attached cascade_3node_setup_with_slots has the > script for this): > Here, slot name was used as slot1 for node1 to node2 and slot2 for > node2 to node3. Then I ran pg_createsubscriber by specifying primary > as node1 and standby as node3. In this case pg_createsubscriber fails > with the following error: > pg_createsubscriber: error: could not obtain replication slot > information: got 0 rows, expected 1 row > [Inferior 1 (process 2623483) exited with code 01] > > This is failing because slot name slot2 is used between node2->node3 > but pg_createsubscriber is checked for slot1, the slot which is used > for replication between node1->node2. > Thoughts? Right. The inconsistency is quite strange. Overall, I felt such a case must be rejected. How should we detect at checking phase? Best Regards, Hayato Kuroda FUJITSU LIMITED https://www.fujitsu.com/
