Re: [HACKERS] oldish libpq bug still in RC2
Ü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 ---888888-- import socket HOST = '' PORT = 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() ---888888-- and then connect to it with psql $ psql -h 127.0.0.1 -p 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
Re: [HACKERS] oldish libpq bug still in RC2
Ü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 donetested by tomorrow evenning the latest. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] oldish libpq bug still in RC2
Hannu Krosing [EMAIL PROTECTED] 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
Re: [HACKERS] oldish libpq bug still in RC2
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 [EMAIL PROTECTED] ---(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
[HACKERS] 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 [EMAIL PROTECTED] ---(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
Re: [HACKERS] oldish libpq bug still in RC2
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? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
