Skip site navigation (1) Skip section navigation (2)

Re: PQexec infinite loop

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Angus Lees <gus(at)switchonline(dot)com(dot)au>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: PQexec infinite loop
Date: 2001-09-13 22:15:18
Message-ID: 10286.1000419318@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Angus Lees <gus(at)switchonline(dot)com(dot)au> writes:
> by doing this we could consistently put libpq into a spin:

Hmmm ... the patch you give is no good as-is, since it will break the
behavior for "normal" errors.  If we want to work around this, we'll
need some way to distinguish persistent inside-libpq failure conditions
from plain old backend error reports.  Looking at resultStatus isn't
enough to tell the difference.

The particular scenario you describe is not something that libpq can
reasonably be expected to defend against --- once the database handle
is disconnected, the "conn" structure is freed, and so that memory
could be reallocated and filled with completely arbitrary contents.
libpq could hardly even be expected to guarantee no core dump, let
alone nice friendly easily-interpreted behavior.  But it does seem that
there might be similar scenarios with more-legitimate causes in which
PQgetResult returns a non-transient error condition, and so the loop
in PQexec never exits.  Maybe another flag field in PGconn is needed?

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Rainer MagerDate: 2001-09-13 22:42:28
Subject: Re: Re: timestamps cannot be created without time zones
Previous:From: Tomasz MyrtaDate: 2001-09-13 21:18:02
Subject: dynamic-static date once again

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group