I just sent in the patch for online index builds to -patches.
. The work to combine the two phases into a single non-transactional command is done. I'm not sure how long to wait
betweenlock checks or how verbose to be about why it's taking so long. I do think we have to print something or else
theDBA won't know if it's hung waiting for something external. Currently it prints a notice the first time it sleeps.
. Also it prints out how many tuples it found which normal index doesn't. Probably that message should go away. On the
otherhand the index stats probably need to be filled in.
. I need to check what locks I'm taking. I think I still have some old code with the wrong locks in it.
. this includes the tid btree opclass sent earlier (with a warning I didn't notice before fixed up). opr_sanity now
failsbut I think that's due to the gin commits not this opclass.
. In case of an error during phase2 the invalid index is left in place. It can be dropped with DROP INDEX. The footwork
toget it dropped in case of an error would be quite tricky but there's a sketch of how to do it in the source.
. no documentation yet, there's not much to write though.
. no regression tests yet. I don't see any way to test this reasonably in the regression tests. I've done some testing
myselfby building indexes while pgbench is running. Then I have to do index scans to see how many records are returned
withindex scans. It wouldn't be easy to automate and even if it were done it wouldn't really be all that great a test.
Thecorner cases found during the development are pretty narrow and will be hard to reliably test.
--
greg
