From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | "H(dot)J(dot) Sanders" <hjs(at)rmax(dot)nl>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Plans for 8.2? |
Date: | 2006-01-13 21:40:48 |
Message-ID: | 20060113214048.GU9017@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Jan 13, 2006 at 01:59:19AM -0700, Michael Fuhr wrote:
> On Fri, Jan 13, 2006 at 01:49:02AM -0700, Michael Fuhr wrote:
> > On Fri, Jan 13, 2006 at 09:30:22AM +0100, H.J. Sanders wrote:
> > > Just one request that would make the transition from another
> > > great database to PostgreSQL a lot easier:
> > >
> > > SET LOCK MODE TO WAIT n
> > >
> > > n = the max.time in second to wait.
> >
> > Will statement_timeout suffice?
>
> (I'm not implying that statement_timeout is equivalent, I'm just
> wondering if you might be able to use it in certain circumstances.)
It strikes me that if we had a way to abort a statement on another
backend, you could abort anything that's been waiting more than x
seconds for a lock via an external process watching pg_locks. Of course,
that would be much more cumbersom than SET LOCK MODE TO WAIT n...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2006-01-13 21:49:02 | Re: Plans for 8.2? |
Previous Message | Jim C. Nasby | 2006-01-13 21:24:52 | Re: Plans for 8.2? |