Interesting GSI index behavior

Couchbase Server
1

Related to debugging an ottoman issue with creating GSI’s via n1ql, I noticed a strange issue, not sure if this is intended or not in the server.

Let’s say I create a new bucket from scratch. I then go into cbq and issue a big pile of CREATE INDEX (…) WITH GSI {“defer_build”:true} statements. (With the intention of later issuing a BUILD INDEX statement).

Further suppose I never issue that BUILD INDEX statement. (Usually because I’ve screwed my code up). So what you end up with is a pile of indexes labeled “Created” at 0% build. Which makes sense, because you haven’t started building them yet. Fine.

The strange part is, if I at this point delete the bucket, and re-create it, I can’t shake those indexes, even if the original CREATE INDEX statements were on that bucket. Indeed re-trying the index creation loop fails, because they already exist!

FWIW, I’m using community-4.0.0 off of a docker container.

One thing I already know resolves this; if I delete the bucket, and do a full-restart on the server, then when it comes back up, the “created but 0% built” indexes are gone, I can create a new bucket, and get on with it.

Is this behavior desirable, or a bug? If I delete a bucket, why would I want any as-yet unbuilt indexes that implicate that bucket to stick around?

2

We should file it as an issue to evaluate it. I can see how it’s at least slightly confusing. I filed MB-19022.

In some ways the behavior does make some sense, as GSI is more global than buckets.

3

The problem is that if a bucket has no active indexes, the indexer does not have an active DCP stream to the bucket. So dropping the bucket will not trigger the cleanup actions. This will be fixed. As a workaround, please DROP INDEX these deferred build indexes manually.