On Wed, 2009-01-21 at 09:01 -0500, Dave Cramer wrote:
> On Wed, Jan 21, 2009 at 8:35 AM, Simon Riggs <simon@2ndquadrant.com>
> wrote:
>
> On Thu, 2009-01-22 at 00:38 +1300, Oliver Jowett wrote:
> > Note that there is no single "main thread"
> Yeh, I meant "the thread that executes the code for that
> session".
> Well, that's actually the client's thread. There isn't really a
> "monitor" thread.
Yup, I know how it works. Just trying to find language to show that the
main code is executed by one thread for each client, hence "main
thread", but yes that is the client's thread.
I understand there currently is not something that we might call a
monitor thread, but I was interested in creating one to allow us to
independently inspect the state of the client threads. Watcher, monitor
thread, call it whatever, but an objective observer of what is occurring
to allow us to record information and take action.
I would prefer to have a worker (client) thread and a watcher thread
than to break the task of the client thread into two.
Anyway, if you guys can see where I'm coming from then that's good. The
important thing for me is the objective, not any specific design: being
able to confirm using automated logging suitable for use in a busy
production system that the client/server interaction is not deadlocked,
so we can argue reasonably that the search for root cause of problems
can exclude (or not) Postgres related code. JDBC is the most important
client, IMHO.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
