Re: pgsql: Restore replication protocol's duplicate command tags
От | Amit Kapila |
---|---|
Тема | Re: pgsql: Restore replication protocol's duplicate command tags |
Дата | |
Msg-id | CAA4eK1JSSD7FVwq+_rOme86jUZTQFzjsNU06hQ4-LiRt1xFmSg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Restore replication protocol's duplicate command tags (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: pgsql: Restore replication protocol's duplicate command tags
|
Список | 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 по дате отправления: