pg_basebackup may fail to send feedbacks.

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: pgsql-hackers(at)postgresql(dot)org
Subject: pg_basebackup may fail to send feedbacks.
Date: 2015-02-02 04:48:34
Message-ID: 20150202.134834.100672846.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, I received an report that pg_basebackup with "-X stream"
always exits with the following error.

> pg_basebackup: could not receive data from WAL stream: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.

The walsender had been terminated by replication timeout a bit
before the above message.

> LOG: terminating walsender process due to replication timeout

====

I digged into this and found that a accumulation of delay in
receiving xlog stream can cause such an error. This hardly occurs
on an ordinary environment but this would be caused by temporary
(or permanent) heavy load on the receiver-side machine. A virtual
machine environment could raises the chance, I suppose.

In HandleCopyStream(), the feedbacks are sent only after breaks
of the xlog stream, so continuous flow of xlog stream prevents it
from being sent with expected intervals. walsender sends
keepalive message for such a case, but it arrives with a long
delay being caught by the congestion of the stream, but this is
not a problem because the keepalive is intended to be sent while
idle.

I think that the status feedback should be sent whenever
standby_message_timeout has elapsed just after (or before) an
incoming message is processed. The seemingly most straightforward
way to fix this is breaking the innner-loop (while(r != 0)) if
the time to feedback comes as the attached patch #1
(0001-Make-sure-to-send-...).

What do you thing about this?

regards,

=====
- How to reproduce the situation.

As mentioned before, this hardly occurs on ordinary
environment. But simulating the heavy load by inserting a delay
in HandleCopyStream() effectively let the error occur.

With the attached patch #2(insert_interval.diff), the following
operation let us see the situation. The walsender reports timeout
although the stream processing is delayed but running steadily.

postgresql.conf:
> wal_level = hot_standby
> max_wal_senders = 2
> wal_sender_timeout = 20s # * 2 of default of standby_message_timeout

Terminal1$ psql postgres
postgres=# CREATE TABLE t1 (a text);
postgres=# ALTER TABLE t1 ALTER COLUMN a SET STORAGE EXTERNAL;
postgres=# INSERT INTO t1 (SELECT repeat('x', 10000) FROM generate_series(0, 99999)); -- about 1GB
postgres=# ^D

Terminal1$ pgbench -i postgres
Terminal1$ pgbench -T 600 -h localhost postgres

Terminal2$ pg_basebackupo -r 32k -X stream -D data -h localhost

... in about a couple of minutes on my environment..

Terminal1:
> LOG: terminating walsender process due to replication timeout

... after another couple of minutes.

Terminal2:
> pg_basebackup: could not receive data from WAL stream: server closed...

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
0001-Make-sure-to-send-feedback-at-desired-timing.patch text/x-patch 1.4 KB
insert_interval.diff text/x-patch 468 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip kumar 2015-02-02 05:02:05 psql doccumentation issue
Previous Message Tom Lane 2015-02-02 04:10:35 Release note bloat is getting out of hand