Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing
Дата
Msg-id 1133901931.3719.22.camel@localhost.localdomain
обсуждение исходный текст
Ответ на Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Ühel kenal päeval, T, 2005-12-06 kell 15:38, kirjutas Tom Lane:
> Hannu Krosing <hannu@skype.net> writes:
> > What I have in mind would be something like this to get both SNAP2 and
> > commit between any transactions:
> 
> > LOOP:
> >     LOCK AGAINST STARTING NEW TRANSACTIONS
> 
> I can hardly credit that "let's block startup of ALL new transactions"
> is a more desirable restriction than "let's block writers to the table
> we wish to reindex".

If the block is short-time (will be removed one way or other in a few
(tenths of) seconds, then this is much more desirable than blocking
writers for a few hours.

The scenario where concurrent create index command is be needed is 24/7
OLTP databases, which can't be taken down for maintenance. Usully they
can be arranged to tolerate postponing a few transactions for one
second.

----------
Hannu




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Ideas for easier debugging of backend problems