Re: oldish libpq bug still in RC2

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>

In response to

Responses

Browse pgsql-hackers by date

  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