Re: transaction timeout

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

In response to

Responses

Browse pgsql-general by date

  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