"David G. Johnston" <david.g.johnston@gmail.com> writes:
> You may find the following to be informative as well.
A general comment on these examples is that we don't intend MVCC
guarantees to hold with respect to tables that are created/dropped
by other sessions midway through your transaction. The reason can
be understood from this example:
Session 1:
BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT * FROM table1; -- establishes session1's snapshot
Session 2:
DROP TABLE table2;
CREATE TABLE table2 ...
Session 1:
SELECT * FROM table2;
Strict MVCC semantics would require that session 1 now see
the old contents of table2, which implies basically that we can't
ever drop tables --- at the point of the DROP, there was absolutely
nothing indicating that session 1 would take any interest in table2,
but after the fact it wants to know about it. That's not how it
works; if DROP is able to obtain exclusive lock on table2, that
table is toast, immediately.
(I think that if you use SERIALIZABLE level, you might get a serialization
failure from the "SELECT * FROM table2", or if you don't then perhaps
it'd be reasonable to fix it so you do. But under no circumstances
are we going to sit on the data in table2 on the off chance that
some transaction might want it later.)
Like Julien, I'm not entirely sure how well this is documented.
There is plenty of detail in [1] though.
regards, tom lane
[1] https://www.postgresql.org/docs/current/mvcc.html
