Alguns comandos de DDL, atualmente apenas o TRUNCATE e as formas de reescrita de tabelas de ALTER TABLE, não são seguros para MVCC, significando que, após o truncamento ou reescrita se tornar efetivo, a tabela aparecerá como estando vazia para as transações concorrentes, se estiverem usando um instantâneo obtido antes da efetivação do comando de DDL. Isto só é um problema para uma transação que não acessou a tabela em questão antes do comando de DDL ser iniciado — qualquer transação que tenha feito isso manteria pelo menos um bloqueio de tabela ACCESS SHARE, que bloquearia o comando DDL até que a transação estivesse concluída. Portanto, estes comandos não causam nenhuma inconsistência aparente no conteúdo da tabela para consultas sucessivas na tabela de destino, mas podem causar inconsistência visível entre o conteúdo da tabela de destino e outras tabelas no banco de dados.

O suporte para o nível de isolamento de transação SERIALIZABLE ainda não foi adicionado aos destinos de replicação por espera ativa (Hot Standby) (descrito em Seção 26.4). O nível de isolamento mais estrito atualmente com suporte no modo de espera ativa é REPEATABLE READ. Ao executar todas as escritas de banco de dados permanentes em transações SERIALIZABLE no servidor primário, garantirá que todos os servidores em-espera finalmente atinjam um estado consistente. Uma transação REPEATABLE READ executada num servidor em espera pode, às vezes, ver um estado transitório inconsistente com qualquer execução serial das transações no servidor primário.

O acesso interno aos catálogos do sistema não é feito usando o nível de isolamento da transação corrente, significando que objetos de banco de dados recém-criados, como tabelas, são visíveis para transações REPEATABLE READ e SERIALIZABLE concorrentes, mesmo que as linhas que eles contêm não sejam. Por outro lado, as consultas que examinam explicitamente os catálogos do sistema não veem linhas representando objetos de banco de dados criados concorrentemente, nos níveis de isolamento mais altos.