On Wed, Sep 29, 2021 at 9:29 PM Tom Lane wrote:
>
> Amit Kapila writes:
> > On Wed, Sep 29, 2021 at 3:47 AM Tom Lane 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_w
Amit Kapila writes:
> On Wed, Sep 29, 2021 at 3:47 AM Tom Lane 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 stand
On Wed, Sep 29, 2021 at 3:47 AM Tom Lane wrote:
>
> I noticed that some test scripts, instead of using wait_for_catchup
> to wait for replication catchup, use ad-hoc code like
>
> my $primary_lsn =
> $primary->safe_psql('postgres', 'select pg_current_wal_lsn()');
> $standby->poll_query_until('po
I noticed that some test scripts, instead of using wait_for_catchup
to wait for replication catchup, use ad-hoc code like
my $primary_lsn =
$primary->safe_psql('postgres', 'select pg_current_wal_lsn()');
$standby->poll_query_until('postgres',
qq{SELECT '$primary_lsn'::pg_lsn <= pg_last_w
