Re: Tricky bugs in concurrent index build

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)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