On Thu, Aug 18, 2005 at 01:33:18PM -0400, Vivek Khera wrote:
Hey Vivek! Nice to hear from you over here. ;)
> The trick is dealing with statement timeouts on shared pool
> connections over mod_perl and Apache::DBI. I haven't satisfied
> myself yet that the timeout will be unset when the n
On Aug 16, 2005, at 3:01 PM, Bill Moseley wrote:
So then I wondered if my application should set an alarm and timeout
with an error if, by odd chance, an update hangs. Trying to be a bit
more robust -- not that the application could recover, but at least it
could spit out an error other than h
Wow, non-blocking lock failure?
Can I take this chance to say an overdue thanks to the Postgresql
developers? A truly commercial grade feature set in a free
database...
On 8/16/05, Matt Miller <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-16 at 12:01 -0700, Bill Moseley wrote:
> > I wondered if m
On Tue, 2005-08-16 at 12:01 -0700, Bill Moseley wrote:
> I wondered if my application should set an alarm and timeout
> with an error if, by odd chance, an update hangs.
Here's a way to handle this under the upcoming 8.1 release:
Before you execute the update you can execute SELECT ... FOR UPDATE
On Tue, Aug 16, 2005 at 08:25:25PM +0200, Martijn van Oosterhout wrote:
> On Tue, Aug 16, 2005 at 11:05:35AM -0700, Bill Moseley wrote:
> > I've read over the docs on Concurrency Control but still not clear
> > about when transactions block other updates, and how to deal with that
> > on the applic
On Tue, Aug 16, 2005 at 11:05:35AM -0700, Bill Moseley wrote:
> I've read over the docs on Concurrency Control but still not clear
> about when transactions block other updates, and how to deal with that
> on the application level.
>
> If I do a BEGIN and an UPDATE in one psql session and then try
