Re: REINDEX CONCURRENTLY 2.0

On 02/02/2015 03:10 PM, Andres Freund wrote:
> I think if we should instead just use the new index, repoint the
> dependencies onto the new oid, and then afterwards, when dropping,
> rename the new index one onto the old one. That means the oid of the
> index will change and some less than pretty grovelling around
> dependencies, but it still seems preferrable to what we're discussing
> here otherwise.

I think that sounds like a good plan. The oid change does not seem like
a too big deal to me, especially since that is what users will get now
too. Do you still think this is the right way to solve this?

I have attached my work in progress patch which implements and is very
heavily based on Michael's previous work. There are some things left to
do but I think I should have a patch ready for the next commitfest if
people still like this type of solution.

I also changed index_set_state_flags() to be transactional since I
wanted the old index to become invalid at exactly the same time as the
new becomes valid. From reviewing the code that seems like a safe change.

A couple of bike shedding questions:

- Is the syntax "REINDEX <type> CONCUURENTLY <object>" ok?

- What should we do with REINDEX DATABASE CONCURRENTLY and the system
catalog? I so not think we can reindex the system catalog concurrently
safely, so what should REINDEX DATABASE do with the catalog indexes?
Skip them, reindex them while taking locks, or just error out?

- What level of information should be output in VERBOSE mode?

What remains to be implemented:

- Support for exclusion constraints
- Look more into how I handle constraints (currently the temporary index
too seems to have the PRIMARY KEY flag)
- Support for the VERBOSE flag
- More testing to catch bugs

Andreas