Re: ALTER TABLE DETACH PARTITION violates serializability

On Fri, Nov 12, 2021 at 3:27 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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