The following bug has been logged on the website:
Bug reference: 7914
Logged by: Shin-ichi MORITA
Email address: s-mor...@beingcorp.co.jp
PostgreSQL version: 8.4.16
Operating system: Windows Server 2012
Description:
Hi great team,
I encountered a strange error during pg_dump as below:
----
pg_dump: Dumping the contents of table "t_file_data" failed: PQgetCopyData()
failed.
pg_dump: Error message from server: lost synchronization with server: got
message type "d", length 21861
pg_dump: The command was: COPY public.t_file_data (c_file_info_id,
c_page_no, c_data) TO stdout;
pg_dump: *** aborted because of error
----
It seems that large tables tend to cause this to happen.
In order to figure out what happens, I looked into
src/interfaces/libpq/fe-protocol3.c.
Then I have found that it is possible that PGconn::inBuffer is
unintentionally enlarging during execution of getCopyDataMessage().
Please look at fe-protocol3.c:1432:
1425: avail = conn->inEnd - conn->inCursor;
1426: if (avail < msgLength - 4)
1427: {
:
1432: if (pqCheckInBufferSpace(conn->inCursor + (size_t) msgLength -
4,
When several messages have been already proccessed and avail < msgLength -
4,
inBuffer will be enlarged without left-justification.
I think that pqCheckInBufferSpace() should be called only when inBuffer is
left-justified like this:
1432: if (conn->inStart == 0 && pqCheckInBufferSpace(conn->inCursor +
(size_t) msgLength - 4,
When inBuffer was not left-justified at that moment, the line 1432 will be
executed again after inBuffer is left-justified in pqReadData() called by
pqGetCopyData3().
Please check this out.
Sorry if I have mistaken.
Note that I did not consider the async case.
Thanks and best regards,
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
