On Fri, Nov 12, 2021 at 3:27 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I wasn't aware of $SUBJECT ... were you?
I wasn't aware of this particular example, but I didn't spend much time worrying about it, because DDL interleaved with DML generally isn't serializable anyway. If you issue "SELECT * FROM some_previously_unacessed_table" in a transaction, it will find some_table even if the XID that created that table is not visible to your snapshot. And conversely if that table has been dropped by some XID that is not visible to your snapshot, you will get an error that the table doesn't exist. There's also ATRewriteTable(), which is not MVCC-aware, and thus if someone applies that to a table before you first access it, you may see rows you shouldn't see and fail to see rows which you should see. I don't see those kinds of cases as being all that different from this one. My judgement is that outwaiting other XIDs would make far more people unhappy than it would make happy. If we want to have that as an optional behavior, I guess that would be OK, but I sure wouldn't make it the default. I feel like I went to quite a bit of effort to keep the lock levels as low as reasonably possible here and to allow as much concurrency as I could, and I bet there are still a LOT more people who are unhappy about things that take more locks than they'd like than there are people who are sad about these kinds of MVCC issues. -- Robert Haas EDB: http://www.enterprisedb.com
