aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorStephen Frost <sfrost@snowman.net>2013-07-15 10:42:27 -0400
committerStephen Frost <sfrost@snowman.net>2013-07-15 10:48:08 -0400
commita3957ac156da7e31da46a2d8e3b6c7669333cc99 (patch)
treea26713732846904c86f4380019907bf76e428f82
parent89c09fe02d9aa77aea28525b97229f61f1d5e471 (diff)
downloadpostgresql-a3957ac156da7e31da46a2d8e3b6c7669333cc99.tar.gz
postgresql-a3957ac156da7e31da46a2d8e3b6c7669333cc99.zip
Correct off-by-one when reading from pipe
In pg_basebackup.c:reached_end_position(), we're reading from an internal pipe with our own background process but we're possibly reading more bytes than will actually fit into our buffer due to an off-by-one error. As we're reading from an internal pipe there's no real risk here, but it's good form to not depend on such convenient arrangements. Bug spotted by the Coverity scanner. Back-patch to 9.2 where this showed up.
-rw-r--r--src/bin/pg_basebackup/pg_basebackup.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/bin/pg_basebackup/pg_basebackup.c b/src/bin/pg_basebackup/pg_basebackup.c
index 19cc9e864e3..eaa69f612a2 100644
--- a/src/bin/pg_basebackup/pg_basebackup.c
+++ b/src/bin/pg_basebackup/pg_basebackup.c
@@ -166,7 +166,7 @@ reached_end_position(XLogRecPtr segendpos, uint32 timeline,
char xlogend[64];
MemSet(xlogend, 0, sizeof(xlogend));
- r = read(bgpipe[0], xlogend, sizeof(xlogend));
+ r = read(bgpipe[0], xlogend, sizeof(xlogend)-1);
if (r < 0)
{
fprintf(stderr, _("%s: could not read from ready pipe: %s\n"),