Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection - Mailing list pgsql-hackers

From Denis Perchine
Subject Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection
Date
Msg-id 3314645575.20000705213418@perchine.com
Whole thread Raw
In response to Re: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (kuznet@ms2.inr.ac.ru)
Responses Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Re[2]: Fwd: Re: Fwd: Problem with recv syscall on socket when other side closed connection  (kuznet@ms2.inr.ac.ru)
List pgsql-hackers
Hello kuznet,

Wednesday, July 05, 2000, 7:06:06 PM, you wrote:

kmiar> Hello!

>> As I recall, the original complaint was precisely that Linux discards
>> the server->client data instead of allowing the client to read it.  This
>> was on a single machine, so there's no issue of whether it got lost in
>> the network.

kmiar> I am sorry. I have already said: it is not truth.

kmiar> Original reporter (Denis) blamed particularly on the fact,
kmiar> that Linux allows to read all queued data until EOF.
kmiar> Try yourself, if you do not believe.

kmiar> Unfortunately, I deleted that his mail, but you can find it
kmiar> in mail archives I think, it was to netdev or to linux-kernel.

I blamed that: Linux gives you EPIPE when you call recv before all
data available is retrieved. If you will try to read AFTER error you
will get all data. Problem is that it makes handling very complicated.
In the case of EPIPE you should try to read again. The problem is that
you should always try only once.

-- 
Best regards,Denis                            mailto:dyp@perchine.com




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: pg_dump and LOs (another proposal)
Next
From: JanWieck@t-online.de (Jan Wieck)
Date:
Subject: update on TOAST status