Re: Reducing relation locking overhead

Поиск
Список
Период
Сортировка
От Csaba Nagy
Тема Re: Reducing relation locking overhead
Дата
Msg-id 1134055437.4779.272.camel@coppola.muc.ecircle.de
обсуждение исходный текст
Ответ на Re: Reducing relation locking overhead  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Reducing relation locking overhead  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
On Thu, 2005-12-08 at 16:05, Tom Lane wrote:
[SNIP]
> There isn't any way for it to do that (ie, be sure everyone else has
> adjusted to the new state of affairs), short of acquiring some sort of
> short-term exclusive lock on the table, which is a really bad idea.
> The pending lock would block other incoming requests on the table until
> all the current users exited their transactions.
> 

But it is an acceptable compromise to lock the table until all current
transactions are over... the alternative for reindexing a big table is
usually to schedule a down-time, which is even worse...

REINDEX is usually used to fix a big tables big index bloat, and that
won't fly without a downtime, or, with this short-term full table lock
in a low-traffic time-slot. 

For my usage patterns I would vote with the table lock if it is just a
means of blocking new transactions until the running ones finish. I'll
just make sure there are none long running when I issue the REINDEX...

Cheers,
Csaba.






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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Reducing contention for the LockMgrLock
Следующее
От: Darcy Buskermolen
Дата:
Сообщение: Re: HOOKS for Synchronous Replication?