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.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services