Hi, It's documented that a failed REINDEX can leave behind a transient index, and I'm not going to speculate on all the conditions that could lead to this situation. However, cancelling a REINDEX CONCURRENTLY will reliably leave behind the index it was building (<index name>_ccnew).
Doesn't a cancellation instruct the process that the user has made a decision regarding the fate of the new version of the index? Is there a situation where the incomplete transient index might need to be inspected following a cancellation? Because if not, why not get it to tidy up after itself? If the process crashed, fair enough, but it just doesn't sit well that leftover artifacts of an aborted operation aren't tidied up, especially since subsequent attempts to REINDEX will find these invalid transient versions and attempt to REINDEX them. Why should the user need to know about them and take manual action in the case of a cancellation? I get the feeling that this is deliberate, and perhaps an attempt to mitigate locking issues, or some other explanation, but the rationale isn't immediately apparent to me if this is the case. Thanks Thom