Re: pgsql: Restore replication protocol's duplicate command tags - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pgsql: Restore replication protocol's duplicate command tags
Date
Msg-id CAA4eK1JSSD7FVwq+_rOme86jUZTQFzjsNU06hQ4-LiRt1xFmSg@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Restore replication protocol's duplicate command tags  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: pgsql: Restore replication protocol's duplicate command tags  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Thu, Oct 15, 2020 at 6:07 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> On 2020-Oct-14, Alvaro Herrera wrote:
>
> > Add a test case that shows the failure.  It might still succeed even
> > without the patch when run on a fast enough server, but it suffices to
> > show the bug in enough cases that it would be noticed in buildfarm.
>
> Hm, this failed on sidewinder.
>

Now, curculio [1] also seems to be failing for the same reason.

>  I think the "wait for catchup" stuff in
> logical replication is broken; I added a wait for sync workers to go
> away after the normal wait_for_catchup, but evidently it is not
> sufficient even with that.
>
>

For the initial table sync, we use below in some of the tests (see
001_rep_changes):

# Also wait for initial table sync to finish
my $synced_query =
  "SELECT count(1) = 0 FROM pg_subscription_rel WHERE srsubstate NOT
IN ('r', 's');";
$node_subscriber->poll_query_until('postgres', $synced_query)
  or die "Timed out while waiting for subscriber to synchronize data";

Is it not possible to use the same thing in this test as well?

[1] - https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=curculio&dt=2020-10-15%2005%3A30%3A43

-- 
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Next
From: Amit Kapila
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables