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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers