It seems that this bug is still lurking in libpq:

http://search.postgresql.org/pgsql-h...9/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

Hannu Krosing <hannu@tm.ee> writes:
> It seems that this bug is still lurking in libpq:
> http://search.postgresql.org/pgsql-h...9/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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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-h...9/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, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Ü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-h...9/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>

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

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

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

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster