Thread: oldish libpq bug still in RC2

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() ?

-- 
Hannu Krosing <hannu@tm.ee>

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?
        regards, tom lane

This item still seems open.  Is it a TODO?

---------------------------------------------------------------------------

Hannu Krosing wrote:
> 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() ?
> 
> -- 
> Hannu Krosing <hannu@tm.ee>
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match
> 

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 

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

Ühel kenal päeval (esmaspäev, 3. jaanuar 2005, 22:29-0500), kirjutas
Bruce Momjian:
> This item still seems open.  Is it a TODO?

Probably. It bit me quite badly when it was discovered.

I'm hoping to get something done&tested by tomorrow evenning the latest.


--
Hannu Krosing <hannu@tm.ee>

Hannu Krosing <hannu@tm.ee> writes:
> Tom Lane:
>> 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

Ah, of course.  Thanks for the test scaffold.  I have checked and
committed a fix.
        regards, tom lane