Re: pgsql: Restore replication protocol's duplicate command tags

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Restore replication protocol's duplicate command tags
Date: 2020-10-15 07:07:04
Message-ID: CAA4eK1JSSD7FVwq+_rOme86jUZTQFzjsNU06hQ4-LiRt1xFmSg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Thu, Oct 15, 2020 at 6:07 AM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2020-10-15 07:10:34 pgsql: Add documentation link to attributes supported by Clang
Previous Message Thomas Munro 2020-10-15 05:40:34 pgsql: Handle EACCES errors from kevent() better.

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2020-10-15 07:08:49 Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Previous Message denni.pat 2020-10-15 06:57:11 Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted