Ü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>