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
On Fri, Aug 7, 2009 at 12:33 PM, Tom Lane wrote:
> BTW, the "SSL renegotiation failure" bit
> suggests that it could have been an OpenSSL bug not a real network
> lossage, so you might want to see how up-to-date your openssl libraries
> are.
Thanks for your comments, Tom. The operation seems more
I wrote:
> Hmm, so it looks like the connection dropped and libpq failed to
> recognize that, or maybe libpq was okay but psql needs to check a bit
> more carefully here. I'll take a look.
I could not reproduce this problem in testing, but after eyeballing
the code awhile I have a theory. It loo
Neil Best writes:
> Tom Lane-2 wrote:
>> Hmm. It looks like psql could get into an infinite loop if the server
>> failed to exit COPY IN mode for some reason, but it's not at all clear
>> how that could happen (or what to do about it). What server version
>> and what psql version is this? What
Tom Lane-2 wrote:
>
> Hmm. It looks like psql could get into an infinite loop if the server
> failed to exit COPY IN mode for some reason, but it's not at all clear
> how that could happen (or what to do about it). What server version
> and what psql version is this? What does the server's l
Neil Best writes:
> psql:copy.sql:8059525: \copy: unexpected response (4)
> psql:copy.sql:8059525: \copy: unexpected response (4)
> psql:copy.sql:8059525: \copy: unexpected response (4)
> psql:copy.sql:8059525: \copy: unexpected response (4)
> psql:copy.sql:8059525: \copy: unexpected response (4)
