On Fri, 2008-06-20 at 18:38 -0400, Bruce Momjian wrote:
Laurent Birtz wrote:
No. The closest thing we have is log_lock_waits in 8.3. I wonder if
you could hack up something to monitor the server logs for such messages
and cancel the queries.
Assuming I can monitor the logs in
2) Is there any hostility about the notion of implementing this feature
into Postgres?
Probabably --- it seems like a narrow use case.
I'll consider this to be the definite answer unless I hear a dissenting
opinion in the next few days.
Yea, I might be wrong.
I think you're
Laurent Birtz wrote:
No. The closest thing we have is log_lock_waits in 8.3. I wonder if
you could hack up something to monitor the server logs for such messages
and cancel the queries.
Assuming I can monitor the logs in this way, how would I cancel the
queries (or lack thereof, in
Bruce Momjian wrote:
Laurent Birtz wrote:
Hello,
I am using Postgres in a high-availability environment and I'd like to
know whether Postgres has provisions to kick off a misbehaving client
that has obtained an advisory lock on the database and won't release it
in a timely fashion. I am not
Laurent Birtz wrote:
Hello,
I am using Postgres in a high-availability environment and I'd like to
know whether Postgres has provisions to kick off a misbehaving client
that has obtained an advisory lock on the database and won't release it
in a timely fashion. I am not worried about
Hello,
I am using Postgres in a high-availability environment and I'd like to
know whether Postgres has provisions to kick off a misbehaving client
that has obtained an advisory lock on the database and won't release it
in a timely fashion. I am not worried about malicious clients, however I
am
