Re: Bug: walsender and high CPU usage

On 09.03.2012 13:40, Fujii Masao wrote:
> I found the bug which causes walsender to enter into busy loop
> when replication connection is terminated. Walsender consumes
> lots of CPU resource (%sys), and this situation lasts until it has
> detected the termination of replication connection and exited.
>
> The cause of this bug is that the walsender loop doesn't call
> ResetLatch at all in the above case. Since the latch remains set,
> the walsender loop cannot sleep on the latch, i.e., WaitLatch
> always returns immediately.
>
> We can fix this bug by adding ResetLatch into the top of the
> walsender loop. Patch attached.
>
> This bug exists in 9.1 but not in 9.2dev. In 9.2dev, this bug has
> already been fixed by the commit
> (cff75130b5f63e45423c2ed90d6f2e84c21ef840). This commit
> refactors and refines the walsender loop logic in addition to
> adding ResetLatch. So I'm tempted to backport this commit
> (except the deletion of wal_sender_delay) to 9.1 rather than
> applying the attached patch. OTOH, attached patch is quite simple,
> and its impact on 9.1 would be very small, so it's easy to backport that.
> Thought?

This patch makes the code that follows bogus:

> 		/*
> 		 * If we don't have any pending data in the output buffer, try to send
> 		 * some more.
> 		 */
> 		if (!pq_is_send_pending())
> 		{
> 			XLogSend(output_message, &caughtup);
>
> 			/*
> 			 * Even if we wrote all the WAL that was available when we started
> 			 * sending, more might have arrived while we were sending this
> 			 * batch. We had the latch set while sending, so we have not
> 			 * received any signals from that time. Let's arm the latch again,
> 			 * and after that check that we're still up-to-date.
> 			 */
> 			if (caughtup && !pq_is_send_pending())
> 			{
> 				ResetLatch(&MyWalSnd->latch);
>
> 				XLogSend(output_message, &caughtup);
> 			}
> 		}

The comment is no longer valid, and the calls to ResetLatch and XLogSend 
are no longer necessary, once you have the ResetLatch() call at the top 
of the loop.

I also think we should backport commit 
cff75130b5f63e45423c2ed90d6f2e84c21ef840, except for the removal of 
wal_sender_delay).

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com