9.4 logical replication - walsender keepalive replies - Mailing list pgsql-hackers

From Steve Singer
Subject 9.4 logical replication - walsender keepalive replies
Date
Msg-id BLU436-SMTP25712B7EF9FC2ADEB87C522DC040@phx.gbl
Whole thread Raw
Responses Re: 9.4 logical replication - walsender keepalive replies  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
In 9.4 we've the below  block of code to walsender.c as

/* * We only send regular messages to the client for full decoded * transactions, but a synchronous replication and
walsendershutdown * possibly are waiting for a later location. So we send pings * containing the flush location every
nowand then.
 
*/
if (MyWalSnd->flush < sentPtr && !waiting_for_ping_response)
{    WalSndKeepalive(true);    waiting_for_ping_response = true;
}


I am finding that my logical replication reader is spending a tremendous 
amount of time sending feedback to the server because a keep alive reply 
was requested.  My flush pointer is smaller than sendPtr, which I see as 
the normal case (The client hasn't confirmed all the wal it has been 
sent).   My client queues the records it receives and only confirms when 
actually processes the record.

So the sequence looks something like

Server Sends LSN 0/1000
Server Sends LSN 0/2000
Server Sends LSN 0/3000
Client confirms LSN 0/2000


I don't see why all these keep alive replies are needed in this case 
(the timeout value is bumped way up, it's the above block that is 
triggering the reply request not something related to timeout)

Steve







pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Spinlocks and compiler/memory barriers
Next
From: Robert Haas
Date:
Subject: Re: better atomics - v0.5