Re: transaction timeout - Mailing list pgsql-general

From Dr NoName
Subject Re: transaction timeout
Date
Msg-id 20050726160050.67082.qmail@web31510.mail.mud.yahoo.com
Whole thread Raw
In response to Re: transaction timeout  (Michael Fuhr <mike@fuhr.org>)
Responses Re: transaction timeout
List pgsql-general
> What's the client doing that takes locks strong
> enough to "lock up
> the entire database"?  Why does the client hang?

yeah, good question. I thought postgres uses
better-than-row-level locking? Could the total
deadlock be caused by a combination of an open
transaction and VACUUM FULL that runs every sunday?

> Since the database
> doesn't currently have a way to detect and handle
> these situations,
> it might be worthwhile to find out what's happening
> to see if it
> can be prevented.

*Anything* can happen. Like, for instance, last week a
user tried to kill the client and only managed to kill
some of the threads. But since the process was not
fully dead, the socket was not closed, so transaction
was still in progress. The point is that the client
must not to be trusted to always do the right thing.
That's why we have things like protected memory,
pre-emptive multitasking, resource limits, etc.
Similarly a database must have the ability to detect a
broken client and kick it out.

thanks,

Eugene



____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs


pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: transaction timeout
Next
From: "Walsh, Richard (Richard)"
Date:
Subject: dropping non-existent tables