Re: Introduce wait_for_subscription_sync for TAP tests

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Introduce wait_for_subscription_sync for TAP tests
Дата
Msg-id CAA4eK1JkUDdmX_L2yaXpFBivnJZVRdNHL_FMaiWLqC7oz_iNfw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Introduce wait_for_subscription_sync for TAP tests  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Introduce wait_for_subscription_sync for TAP tests  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
On Tue, Jul 26, 2022 at 1:12 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Tue, Jul 26, 2022 at 2:01 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > 2.
> > +    # wait for the replication to catchup if required.
> > +    if (defined($publisher))
> > +    {
> > + croak 'subscription name must be specified' unless defined($subname);
> > + $publisher->wait_for_catchup($subname, 'replay');
> > +    }
> > +
> > +    # then, wait for all table states to be ready.
> > +    print "Waiting for all subscriptions in \"$name\" to synchronize data\n";
> > +    my $query = qq[SELECT count(1) = 0
> > +     FROM pg_subscription_rel
> > +     WHERE srsubstate NOT IN ('r', 's');];
> > +    $self->poll_query_until($dbname, $query)
> > + or croak "timed out waiting for subscriber to synchronize data";
> >
> > In the tests, I noticed that a few places did wait_for_catchup after
> > the subscription check, and at other places, we did that check before
> > as you have it here. Ideally, I think wait_for_catchup should be after
> > confirming the initial sync is over as without initial sync, the
> > publisher node won't be completely in sync with the subscriber.
>
> What do you mean by the last sentence? I thought the order doesn't
> matter here. Even if we do wait_for_catchup first then the
> subscription check, we can make sure that the apply worker caught up
> and table synchronization has been done, no?
>

That's right. I thought we should first ensure the subscriber has
finished operations if possible, like in this case, it can ensure
table sync has finished and then we can ensure whether publisher and
subscriber are in sync. That sounds more logical to me.

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Matthias van de Meent
Дата:
Сообщение: Re: Improving btree performance through specializing by key shape, take 2
Следующее
От: Matthias van de Meent
Дата:
Сообщение: Re: Non-replayable WAL records through overflows and >MaxAllocSize lengths