> 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?
Yeps.
> 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.
Now I get:
db=> select count(*) from pg_class;
count
-------
28531
(1 row)
db=> select count(*) from pg_class;
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>
Looks much more reasonable. But I do not get messages about shutdown.
With a patch enclosed it will perform like with ECONNRESET.
Shouldn't I emulate EOF when EPIPE?
--
Sincerely Yours,
Denis Perchine
----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------
