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 between lock checks or how verbose to be about why it's taking so long. I do think we have to print something or else the DBA 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 other hand 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 fails but 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 to get 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 myself by building indexes while pgbench is running. Then I have to do index scans to see how many records are returned with index scans. It wouldn't be easy to automate and even if it were done it wouldn't really be all that great a test. The corner cases found during the development are pretty narrow and will be hard to reliably test. -- greg ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
