Re: Apparent walsender bug triggered by logical replication
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Petr Jelinek <petr.jelinek@2ndquadrant.com>
Cc: pgsql-hackers@postgreSQL.org
Date: 2017-06-30T02:46:30Z
Lists: pgsql-hackers
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 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. regards, tom lane
Commits
-
Reduce delay for last logicalrep feedback message when master goes idle.
- f32678c0163d 10.0 landed
-
Shorten timeouts while waiting for logicalrep worker slot attach/detach.
- 799f8bc76a92 10.0 landed
-
Fix walsender to exit promptly if client requests shutdown.
- fca85f8ef157 10.0 landed
- e9d4aa594f2c 9.6.4 landed
- 5aa8db0148e7 9.4.13 landed
- 446914f6b69a 9.5.8 landed