I have encountered the symmetric error to this -> PGRES_COPY_OUT.
We are using a foreign data wrapper into a large (and unnamed) database
system which generates a substantial pipeline of rows for copyout to bring
back through libPQ to respond to the psql request.
If the back end is blown away the request hangs in the perl command line
script containing the psql command. That command is then terminated with an
alarm(60) call, which was unfortunately a too short timeout.
Nevertheless, the gigabyte of error messages (one per row I assume) that are
generated is probably too much error notification. One (or two) error
message(s) would do. And the fix should possibly look something like:
/*
* Make sure we have pumped libpq dry of results; else it may still
be in
* ASYNC_BUSY state, leading to false readings in, eg, get_prompt().
*/
while ((result = PQgetResult(pset.db)) != NULL)
{
success = false;
psql_error("\\copy: unexpected response (%d)\n",
PQresultStatus(result));
/* if still in COPY IN or COPY OUT state, try to get out of it */
if (PQresultStatus(result) == PGRES_COPY_IN || PQresultStatus(result) ==
PGRES_COPY_OUT)
PQputCopyEnd(conn, _("trying to exit copy mode"));
PQclear(result);
}
I think this becomes an issue only when foreign data wrappers are used,
because both ends of the conversation can die with a pipeline of data being
shoveled through a shared library call under the foreign data wrapper, while
postgres bravely and pointlessly carries on.
Charlie ...
--
View this message in context: http://postgresql.1045698.n5.nabble.com/copy-unexpected-response-4-tp1922077p5461710.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
