Five years after removing SnapshotNow, PostgreSQL still has very little in the way of DDL that can execute concurrently with user queries, and many of the facilities that do exist have significant and sometimes painful limitations. In this talk, I'll give an overview of the problems that have stymied previous attempts to reduce lock levels and design new concurrent DDL facilities. The removal of SnapshotNow provides only a very limited guarantee about how sane catalog lookups can be assumed to be in the presence of concurrent DDL. The heavyweight lock manager, the shared invalidation system, and the relcache are interrelated subsystems with complex interactions whose basic design presupposes that concurrent DDL does not exist. Query planning relies on certain information remaining static between plan time and execution time both for both efficiency and correctness. Deadlock hazards hinder efforts to keep the time for which strong relation locks are held to a minimum. I'll discuss these and other problems that make implementing concurrent DDL correctly an exceptionally hard problem within the PostgreSQL infrastructure.