seil...@so-net.net.tw wrote:
The following listening worker thread behaves as expected if I insert/delete rows
into/from table "t1" in psql prompt.
My trouble is when the SQL execution worker thread inserts/ deletes rows into/from table
"t1", the listening worker thread then goes crazy: PQnotifies() always returns
NULL which pushes the listening thread to grab all CPU power because select() returns
immediately in every iteration. The weird part is that select() says that there is
something available but PQnotifies() returns NULL.
..
Please ignore this question!
My connection pool implementation seems to have flaw. Somehow and somewhere the
connection acquired by a thread is robbed by other threads. The PGconn sending
"LISTEN NotifyMe" becomes different from the PGconn passed to PQsocket(),
PQconsumeInput(), and/or PQnotifies().
I was looking at it carefully, and was about to ask about the
connection- in particular whether it was shared across threads etc. Glad
you've found the issue, I've been caught by something very similar using
list/notify on Lazarus/FPC where you can end up with several handles
only one of which is reliable.
Please also pardon me for asking inappropriate questions like this one. As far
as I can recall, every issue I encountered before always finally proved that
PostgreSQL is flawless.
But at least it demonstrates that somebody's using that facility.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
