[brianberns]

> REINDEX INDEX CONCURRENTLY index_name;

> If for some reason you had to stop the rebuild in the middle, the new index will not be dropped. Instead, it will be left in an invalid state and consume space.

Well, that sure sounds like a bug in PostreSQL to me.

[striking]

Well, you can't just delete it. It is an object that was created by some user and there's no good reason for the database to get rid of it automatically. The database keeps a record of the invalid thing, even though it is invalid.

[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.

[voganmother42]

pretty well documented behavior as far as concurrent: https://www.postgresql.org/docs/current/sql-createindex.html...