Horton

Re: Apparent walsender bug triggered by logical replication

Petr Jelinek <petr.jelinek@2ndquadrant.com>

View thread View on postgr.es
From: Petr Jelinek <petr.jelinek@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Date: 2017-06-30T01:31:31Z
Lists: pgsql-hackers 
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

Commits

  1. Reduce delay for last logicalrep feedback message when master goes idle.

  2. Shorten timeouts while waiting for logicalrep worker slot attach/detach.

  3. Fix walsender to exit promptly if client requests shutdown.