Certaines commandes DDL, actuellement seulement TRUNCATE(7) et les formes d'ALTER TABLE(7) qui réécrivent la table, ne sont pas sûres au niveau MVCC. Ceci signifie que, après la validation d'une troncature ou d'une réécriture, la table apparaîtra vide aux transactions concurrentes si elles utilisaient une image de la base datant d'avant la validation de la commande DDL. Ceci ne sera un problème que pour une transaction qui n'a pas encore accédé à la table en question avant le lancement de la commande DDL -- toute transaction qui a fait cela détiendra au moins un verrou de type ACCESS SHARE sur la table, ce qui bloquera la commande DDL jusqu'à la fin de la transaction. Donc ces commandes ne causeront pas d'incohérence apparente dans le contenu de la table pour des requêtes successives sur la table cible, mais elles seront la cause d'incohérence visible entre le contenu de la table cible et les autres tables de la base.

L'accès interne aux catalogues systèmes n'est pas réalisée en utilisant le niveau d'isolation de la transaction courante. Cela signifie que les objets nouvellement créés d'une base, comme les tables, sont visibles aux transactions Repeatable Read et Serializable, même si les lignes qu'elles contiennent ne le sont pas. À l'inverse, les requêtes qui examinent explicitement les catalogues systèmes ne voient pas les lignes représentant les objets nouvellement créés en concurrence, dans les plus hauts niveaux d'isolation.