On 30/06/17 04:46, Tom Lane wrote:
> Petr Jelinek <petr.jelinek@2ndquadrant.com> writes:
>> On 30/06/17 02:07, Tom Lane wrote:
>>> I'm also kind of wondering why the "behind the apply" path out of
>>> LogicalRepSyncTableStart exists at all; as far as I can tell we'd be much
>>> better off if we just let the sync worker exit always as soon as it's done
>>> the initial sync, letting any extra catchup happen later. The main thing
>>> the current behavior seems to be accomplishing is to monopolize one of the
>>> scarce max_sync_workers_per_subscription slots for the benefit of a single
>>> table, for longer than necessary. Plus it adds additional complicated
>>> interprocess signaling.
>
>> Hmm, I don't understand what you mean here. The "letting any extra
>> catchup happen later" would never happen if the sync is behind apply as
>> apply has already skipped relevant transactions.
>
> Once the sync worker has exited, we have to have some other way of dealing
> with that. I'm wondering why we can't let that other way take over
We make apply wait for the sync worker to get to expected position if it
was behind and only then continue, we can't exactly do that if the apply
already skipped some changes.
> immediately. The existing approach is inefficient, according to the
> traces I've been poring over all day, and frankly I am very far from
> convinced that it's bug-free either.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services