Search Postgresql Archives

Re: transaction timeout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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".

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux