> >> 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 th
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 th
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 thereo
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 w
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 m
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 c
