]> granicus.if.org Git - postgresql/commit
Avoid slow shutdown of pg_basebackup.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 27 Apr 2017 22:27:02 +0000 (18:27 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 27 Apr 2017 22:27:02 +0000 (18:27 -0400)
commit7834d20b57a4320308c3f8262fabf898f89e6a71
tree29c60e8ff7fa45a9f2b0f417435c2ea80835f67b
parent9f11fcec6624511ca85c1a6b049201be1fed6ef4
Avoid slow shutdown of pg_basebackup.

pg_basebackup's child process did not pay any attention to the pipe
from its parent while waiting for input from the source server.
If no server data was arriving, it would only wake up and check the
pipe every standby_message_timeout or so.  This creates a problem
since the parent process might determine and send the desired stop
position only after the server has reached end-of-WAL and stopped
sending data.  In the src/test/recovery regression tests, the timing
is repeatably such that it takes nearly 10 seconds for the child
process to realize that it should shut down.  It's not clear how
often that would happen in real-world cases, but it sure seems like
a bug --- and if the user turns off standby_message_timeout or sets
it very large, the delay could be a lot worse.

To fix, expand the StreamCtl API to allow the pipe input FD to be
passed down to the low-level wait routine, and watch both sockets
when sleeping.

(Note: AFAICS this issue doesn't affect the Windows port, since
it doesn't rely on a pipe to transfer the stop position to the
child thread.)

Discussion: https://postgr.es/m/6456.1493263884@sss.pgh.pa.us
src/bin/pg_basebackup/pg_basebackup.c
src/bin/pg_basebackup/pg_receivewal.c
src/bin/pg_basebackup/receivelog.c
src/bin/pg_basebackup/receivelog.h