Ühel kenal päeval (kolmapäev, 22. detsember 2004, 11:34-0500), kirjutas
Tom Lane:
> Hannu Krosing <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faqs/FAQ.html

Reply via email to