Re: REINDEX CONCURRENTLY 2.0

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: REINDEX CONCURRENTLY 2.0
Дата
Msg-id 20141113012537.GA1791@alvin.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: REINDEX CONCURRENTLY 2.0  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: REINDEX CONCURRENTLY 2.0  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Andres Freund wrote:
> On 2014-11-12 18:23:38 -0500, Robert Haas wrote:

> > > The problem is that it's very hard to avoid the wrong index's
> > > relfilenode being used when swapping the relfilenodes between two
> > > indexes.
> > 
> > How about storing both the old and new relfilenodes in the same pg_class entry?
> 
> That's quite a cool idea
> 
> [think a bit]
> 
> But I think it won't work realistically. We have a *lot* of
> infrastructure that refers to indexes using it's primary key.

Hmm, can we make the relmapper do this job instead of having another
pg_class column?  Essentially the same sketch Robert proposed, instead
we would initially set relfilenode=0 and have all onlookers use the
relmapper to obtain the correct relfilenode; switching to the new
relfilenode can be done atomically, and un-relmap the index once the
process is complete.

The difference from what Robert proposes is that the transient state is
known to cause failures for anyone not prepared to deal with it, so it
should be easy to spot what places need adjustment.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



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

Предыдущее
От: Andreas Karlsson
Дата:
Сообщение: Re: Using 128-bit integers for sum, avg and statistics aggregates
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: REINDEX CONCURRENTLY 2.0