Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] libpq error codes

From: Denis Perchine <dyp(at)perchine(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: [GENERAL] libpq error codes
Date: 2000-06-22 08:05:34
Message-ID: 00062215140104.00479@dyp (view raw, whole thread or download thread mbox)
Lists: pgsql-generalpgsql-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?

> 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;
(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(at)perchine(dot)com
FidoNet: 2:5000/120.5

Attachment: fe-misc.c.patch
Description: text/plain (823 bytes)

In response to


pgsql-patches by date

Next:From: Hiroshi InoueDate: 2000-06-22 11:09:07
Subject: RE: Big 7.1 open items
Previous:From: Philip J. WarnerDate: 2000-06-22 07:50:15
Subject: Re: Big 7.1 open items

pgsql-general by date

Next:From: Eric DuDate: 2000-06-22 10:43:34
Subject: Why can't I create two tables that are foreign keys for each other?
Previous:From: Tom LaneDate: 2000-06-22 07:30:19
Subject: Re: libpq error codes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group