Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit70066eb

Browse files
committed
Insert into getCopyDataMessage() the same logic that already existed in the
main code path for enlarging libpq's input buffer in one swoop when needing toread a long data message. Without this, the code will double the buffer size,read more data, notice it still hasn't got the whole message, and repeat tillit finally has a large enough buffer. Which wastes a lot of data-movingeffort and also memory (since malloc probably can't do anything very usefulwith the freed-up smaller buffers). Not sure why this wasn't there already;certainly the COPY data path is a place where we're quite likely to see longdata messages. I'm not backpatching though, since this is just a marginalperformance issue rather than a real bug.
1 parenta44174c commit70066eb

File tree

1 file changed

+18
-1
lines changed

1 file changed

+18
-1
lines changed

‎src/interfaces/libpq/fe-protocol3.c

Lines changed: 18 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88
*
99
*
1010
* IDENTIFICATION
11-
* $PostgreSQL: pgsql/src/interfaces/libpq/fe-protocol3.c,v 1.33 2008/01/15 22:18:20 tgl Exp $
11+
* $PostgreSQL: pgsql/src/interfaces/libpq/fe-protocol3.c,v 1.34 2008/01/17 21:21:50 tgl Exp $
1212
*
1313
*-------------------------------------------------------------------------
1414
*/
@@ -1305,7 +1305,24 @@ getCopyDataMessage(PGconn *conn)
13051305
}
13061306
avail=conn->inEnd-conn->inCursor;
13071307
if (avail<msgLength-4)
1308+
{
1309+
/*
1310+
* Before returning, enlarge the input buffer if needed to hold
1311+
* the whole message. See notes in parseInput.
1312+
*/
1313+
if (pqCheckInBufferSpace(conn->inCursor+msgLength-4,conn))
1314+
{
1315+
/*
1316+
* XXX add some better recovery code... plan is to skip over
1317+
* the message using its length, then report an error. For the
1318+
* moment, just treat this like loss of sync (which indeed it
1319+
* might be!)
1320+
*/
1321+
handleSyncLoss(conn,id,msgLength);
1322+
return-2;
1323+
}
13081324
return0;
1325+
}
13091326

13101327
/*
13111328
* If it's a legitimate async message type, process it. (NOTIFY

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp