[brianberns]

The good reason to get rid of it automatically: It takes up space.

Is there any good reason to keep it? (The fact that it was "created by some user" doesn't seem like much of a reason.)

IMHO, creating an index should be atomic: Either you end up with a valid index, or you end up with nothing.

[striking]

It can't be atomic if it's done `CONCURRENTLY`. You can't even do that in a transaction, Postgres will tell you it won't work. By using `CONCURRENTLY`, you're making it clear that you will handle atomicity yourself, and as a result Postgres needs to provide you with the tools to do it.

Want real atomicity? Don't use `CONCURRENTLY`.

[Buttons840]

I had the same thoughts. Is there any reason to keep it? Is there any scenario where that invalid index could be useful?

[jeltz]

The reason is to make sure aborting the command is fast and safe. PostgreSQL has no infrastructure for spawn background jobs to clean up stuff like this on aborted queries. A patch would probably welcome if it could be done in a good way.