Re: oldish libpq bug still in RC2 - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: oldish libpq bug still in RC2
Date
Msg-id 1104970964.13593.3.camel@fuji.krosing.net
Whole thread Raw
In response to Re: oldish libpq bug still in RC2  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: oldish libpq bug still in RC2  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Ühel kenal päeval (kolmapäev, 22. detsember 2004, 11:34-0500), kirjutas
Tom Lane:
> Hannu Krosing <hannu@tm.ee> writes:
> > It seems that this bug is still lurking in libpq:
> > http://search.postgresql.org/pgsql-hackers/2004-09/msg00703.php
>
> > Is anybody working on it, or should I try something myself, perhaps just
> > replacing the lone recv() with pqsecure_read() ?
>
> Go for it.  The difficulty I think is testing that the failure path
> actually does the right thing.  Do you have the ability to provoke
> the failure on demand?

the easiest way to provoke it is running the following code in a python
interpreter

---8<----8<----8<----8<----8<----8<--
import socket
HOST = ''
PORT = 5555

def close_on_connect_server():   s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)   s.bind((HOST, PORT))
s.listen(1)  conn, addr = s.accept()   print 'Connected by', addr   conn.close() 

close_on_connect_server()

---8<----8<----8<----8<----8<----8<--

and then connect to it with psql

$ psql -h 127.0.0.1 -p 5555 anydb

this causes the python function to terminate and psql will start using
all available CPU in tight recv() loop.

I'm not sure I will get around to fixing it very soon , though I hoped I
can.

--
Hannu Krosing <hannu@tm.ee>


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: CSV arm check failure
Next
From: Hannu Krosing
Date:
Subject: Re: oldish libpq bug still in RC2