Re: Reducing relation locking overhead

Поиск
Список
Период
Сортировка
От Qingqing Zhou
Тема Re: Reducing relation locking overhead
Дата
Msg-id dmto9l$1h38$1@news.hub.org
обсуждение исходный текст
Ответ на Re: Reducing relation locking overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Reducing relation locking overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> wrote
>
> The real situation is that you must hold at least AccessShareLock on the
> table throughout the entire operation, else you have no defense against
> (say) someone dropping the index or the entire table out from under you.
> And when you add onto this lock in order to lock out writers
> temporarily, you are engaging in a lock upgrade, which can deadlock
> against any sort of exclusive lock request.  The fact that you've been
> holding the AccessShareLock for quite a long time means that the window
> for deadlock problems is very wide.
>

Maybe the deadlock problem is solvable, our current deadlock removal 
mechanism is like this:
/* who wakes up first who removes himself -- quite unfair :-( */RemoveFromWaitQueue(MyProc);

What if we change to cost-based removal, i.e., remove the one whose cost is 
smaller. In this case, an two-days-to-be-done reindex should never get 
killed.

Regards,
Qingqing






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

Предыдущее
От: Qingqing Zhou
Дата:
Сообщение: Re: [PERFORM] Network permormance under windows (fwd)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [PATCHES] snprintf() argument reordering not working under