Re: pgsql: Restore replication protocol's duplicate command tags
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-15T07:07:04Z
Lists: 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.
Commits
-
Fix query in new test to check tables are synced
- 9f783aea669f 13.1 landed
- 7f4708818317 14.0 landed
-
Restore replication protocol's duplicate command tags
- 72e43fc313e9 13.1 cited
-
Fix bogus completion tag usage in walsender
- 07082b08cc5d 14.0 cited