BUG #14237: Terrible performance after accidentally running 'drop index' for index still being created

The following bug has been logged on the website:

Bug reference: 14237
Logged by: David Waller
Email address: dwaller(at)microsoft(dot)com
PostgreSQL version: 9.3.7
Operating system: Linux (Ubuntu)
Description:

Summary: While running ‘create index concurrently’ on a very large table,
running ‘drop index’ for the same index caused Postgres to perform terribly
badly, until the ‘create index’ server process was killed. I would expect
that the ‘drop index’ would either fail immediately, or wait, without
performance impact, until the ‘create index concurrently’ had completed.

In detail:

I started adding an index to a large table using 'create index concurrently
...' (I was running the command using a Rails migration, connecting to
Postgres remotely, via PgBouncer.) It seems that something failed in the
connection to Postgres as my migration terminated with an error after about
1.5 hours (for comparison creating this index successfully took about 3.5
hours).

\d table_name showed the index marked as invalid so I ran 'drop index',
intending to run the index creation again. The average query duration
against this database immediately increased from ~1ms to ~250ms, and stayed
in the range 50–350ms for the next ten minutes, until someone spotted that
there was still a process on the server that was running ‘create index’.
Killing that process caused performance to return to normal.

This was rather bad for the availability of our application during those ten
minutes!

I would expect that running ‘drop index’ while that index is still being
created would either fail immediately, or wait, without performance impact,
until the ‘create index concurrently’ had completed.