Postgres VIEW locking: CREATE OR REPLACE vs. DROP and CREATE

Question

My question relates to a production incident in which it was necessary to replace a poorly performing Postgres VIEW under load. We tried numerous times to redefine the VIEW using CREATE OR REPLACE; this was not successful because the DDL query was blocked by many other SELECT queries. Then, just before we switched the production db to a replica (desperation move) we tried DROP and it seemed to succeed almost immediately. We were then able to create the view. This incident has become somewhat controversial because we can't find any documentation that differentiates the locking behavior of CREATE OR REPLACE from DROP, then CREATE. Some are wondering: did this really happen? Hoping to get some insights from those familiar with Postgres internals.

Answer 1

You were just lucky, and no long running transaction or query happened to be using the view when you dropped it.