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  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables