Re: [GENERAL] libpq error codes
От | Denis Perchine |
---|---|
Тема | Re: [GENERAL] libpq error codes |
Дата | |
Msg-id | 00062215140104.00479@dyp обсуждение исходный текст |
Ответы |
Re: Re: [GENERAL] libpq error codes
|
Список | pgsql-patches |
> 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 ----------------------------------
Вложения
В списке pgsql-patches по дате отправления: