Re: transaction timeout

Поиск
Список
Период
Сортировка
От Dr NoName
Тема Re: transaction timeout
Дата
Msg-id 20050726160050.67082.qmail@web31510.mail.mud.yahoo.com
обсуждение исходный текст
Ответ на Re: transaction timeout  (Michael Fuhr <mike@fuhr.org>)
Ответы Re: transaction timeout  (Paul Tillotson <spam1011@adelphia.net>)
Список 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


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: transaction timeout
Следующее
От: "Walsh, Richard (Richard)"
Дата:
Сообщение: dropping non-existent tables