Re: Tricky bugs in concurrent index build - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Tricky bugs in concurrent index build
Date
Msg-id 87wt8ys1nv.fsf@enterprisedb.com
Whole thread Raw
In response to Re: Tricky bugs in concurrent index build  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Tricky bugs in concurrent index build
Next
From: "Larry Rosenman"
Date:
Subject: Re: Autovacuum on by default?