Denis Perchine <dyp@perchine.com> writes:
>>>> db=> select count(*) from pg_class;
>>>> pqReadData() -- read() failed: errno=32
>>>> ���������� �����
>>
>> The two obvious questions about this are (a) what is errno 32 on
>> your system and (b) why is your strerror() yielding garbage instead
>> of an appropriate error message?
> a. It's broken pipe
> b. Sorry, it's (a) in russian.
Duh, should've figured it was something like that. Didn't show up
as anything much on my display...
>> On my system errno 32 is EPIPE, but surely read() should never
>> return EPIPE.
> That's right... But what should read return if connection is closed by
> other side?
EOF, no more and no less. It is not for the kernel to decide whether
the connection closure represents an application-level error or not.
Sounds like someone has managed to blow this badly in recent Linux TCP
stacks. Care to file a kernel bug report?
In the meantime, it's probably reasonable for libpq to treat EPIPE from
read() the same as EOF --- if I recall correctly, it already tests for
ECONNRESET instead of EOF from kernels that have that variety of
braindamage, so adding a defense against this variety is fair game.
If you look in src/interfaces/libpq/fe-misc.c the places to fix should
be obvious (but note there are two or three of them, not just one).
Please try it out and submit a patch after you've verified it fixes
your problem.
regards, tom lane
