From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: oldish libpq bug still in RC2 |
Date: | 2005-01-06 00:22:44 |
Message-ID: | 1104970964.13593.3.camel@fuji.krosing.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ühel kenal päeval (kolmapäev, 22. detsember 2004, 11:34-0500), kirjutas
Tom Lane:
> Hannu Krosing <hannu(at)tm(dot)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(at)tm(dot)ee>
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2005-01-06 08:46:11 | Re: [HACKERS] Final call for translation updates |
Previous Message | Stephen Birch | 2005-01-05 23:16:07 | Re: [HACKERS] Re: ECPG documentation |