Re: Tricky bugs in concurrent index build

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: Tricky bugs in concurrent index build
Дата
Msg-id 87wt8ys1nv.fsf@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Tricky bugs in concurrent index build  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Gregory Stark <stark@enterprisedb.com> writes:
>> I was also considering going ahead and implementing Hannu's ALTER INDEX SET
>> UNIQUE too.
>
> Don't waste your time, when we don't have an algorithm that would make
> it work.  It's too late for 8.2 anyway...

Oh, I think ALTER INDEX SET UNIQUE is easy, at least algorithm-wise. We set
the index to be unique, then wait until everyone can see it. Then we scan to
make sure there's only one live tuple for each key value. As long as it's
unique in our snapshot and we can be sure that any concurrent changes will
preserve that property then we can be sure it's good.

Hm, I suppose we have to keep the index marked invalid during this operation
so it doesn't appear as if there's a promise that the data is unique. That's
fine for freshly built concurrent indexes but not so nice for an existing
non-unique index. We might need a new column induniqueisvalid that indicates
that a unique constraint can't be trusted yet.

I suppose it's 8.3 material. And maybe not even the most urgent item either.


--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Tricky bugs in concurrent index build
Следующее
От: "Larry Rosenman"
Дата:
Сообщение: Re: Autovacuum on by default?