Angus Lees <gus@switchonline.com.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
