Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing
Date
Msg-id 1133901931.3719.22.camel@localhost.localdomain
Whole thread Raw
In response to Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Concurrent CREATE INDEX, try 2 (was Re: Reducing relation locking overhead)
Next
From: Bruce Momjian
Date:
Subject: Re: Ideas for easier debugging of backend problems