Amit Kapila <amit.kapila16@gmail.com> writes:
> On Wed, Sep 29, 2021 at 3:47 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It seems to me that for most purposes wait_for_catchup's approach is
>> strictly worse, for two reasons:
>> 1. It continually recomputes the primary's pg_current_wal_lsn().
>> 2. It's querying the primary's view of the standby's state, which
>> introduces a reporting delay.
> I can't comment on all the use cases of wait_for_catchup() but I think
> there are some use cases in logical replication where we need the
> publisher to use wait_for_catchup after setting up the replication to
> ensure that wal sender is started and in-proper state by checking its
> state (which should be 'streaming'). That also implicitly checks if
> the wal receiver has responded to initial ping requests by sending
> replay location.
Yeah, for logical replication we can't look at the subscriber's WAL
positions because they could be totally different. What I'm on
about is the tests that use physical replication. I think examining
the standby's state directly is better in that case, for the reasons
I cited.
I guess the question of interest is whether it's sufficient to test
the walreceiver feedback mechanisms in the context of logical
replication, or whether we feel that the physical-replication code
path is enough different that there should be a specific test for
that combination too.
regards, tom lane
