From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | Dr NoName <spamacct11(at)yahoo(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: transaction timeout |
Date: | 2005-07-26 15:50:43 |
Message-ID: | 1122393043.15145.72.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 2005-07-26 at 10:33, Dr NoName wrote:
> Yeah, that's what we have to resort to now, but that's
> not a solution. Until we kill the client, the entire
> database is locked (or, at least the tables that other
> clients need to write to, which is effectively the
> same thing). This is annoying enough during the week
> but it's especially a problem on weekends when none of
> the developers are in the office.
OK, for the third or fourth time, what kind of locks is your application
taking out that can lock the whole database?
>
> A single client should not be able to bring the entire
> database down.
A single client running a large unconstrained join can easily bring both
postgresql or Oracle to its knees. Their very nature, of handling
hundreds of users accessing large amounts of data makes databases prone
to such problems, and requires you to carefully design your applications
so as not to do things that cause the database to hiccup.
> The DB should recognize that the client
> went down and roll back the transaction.
How, exactly, can PostgreSQL (or any other database) recognize a hung
client versus one that's waiting for an hour on user input?
> That would be
> the ideal solution. Anything else we can do to remedy
> the situation?
Yes, tell us what you're doing that "locks the whole database".
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-07-26 15:51:24 | Re: transaction timeout |
Previous Message | Josef Springer | 2005-07-26 15:43:10 | Please help: Running Win2k with CP1252 codepage |