Concurrent index creation
When you build an index normally, it locks the table against writes. This means that reads using SELECT against the table will work fine, but any attempt to insert, update, or delete a row in it will block until the index creation is finished. The statement will pause and wait for the index lock to be released, instead of throwing an error immediately. As index rebuilding on large tables can easily take hours, that's a problem. There's some potential for a deadlock producing error here as well, if the client backend already had some locks on that table before the index build began.
Accordingly, on any production database with significant table sizes, where a user being blocked for a long time is an issue, you usually want to build indexes using CREATE INDEX CONCURRENTLY. This is not the default because the concurrent index build is much less efficient than the standard one that takes a lock. It scans the table once to initially build the index, then...
