Re: transaction timeout

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: transaction timeout
Дата
Msg-id 1122393043.15145.72.camel@state.g2switchworks.com
обсуждение исходный текст
Ответ на Re: transaction timeout  (Dr NoName <spamacct11@yahoo.com>)
Ответы Re: transaction timeout  (Dr NoName <spamacct11@yahoo.com>)
Список 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".

В списке pgsql-general по дате отправления:

Предыдущее
От: Josef Springer
Дата:
Сообщение: Please help: Running Win2k with CP1252 codepage
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: transaction timeout