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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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