From PostgreSQL wiki
This is an initial discussion of what behavior "Serializable DDL" might have in PostgreSQL.
- Right now, when two serializable transactions run, you can have t1 begin first, then t2 starts and creates a table, t2 then commits. t1 started first, and so it can't see the new table's entry in pg_class, but because we use "SnapshotNow" for table lookups, t1 can actually select from t2's new table. - We have to address the issue of FKs being added against existing tables, or even being for new tables, and what the "right" answer is - We already have some mechanics to deal with indexes being added and keeping them from being visible "too early" (indcheckmin) - We may have to add similar mechanics for constraints, again, to avoid them being visible "too early"
What needs to be visible immediately and what doesn't?