From: | Dr NoName <spamacct11(at)yahoo(dot)com> |
---|---|
To: | Michael Fuhr <mike(at)fuhr(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: transaction timeout |
Date: | 2005-07-26 16:00:49 |
Message-ID: | 20050726160050.67082.qmail@web31510.mail.mud.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Walsh, Richard (Richard) | 2005-07-26 16:04:08 | dropping non-existent tables |
Previous Message | Alvaro Herrera | 2005-07-26 15:51:24 | Re: transaction timeout |