Questão de Banco de Dados — Concorrência em Banco de Dados — FUNDATEC 2025

MVCC no PostgreSQL – Visibilidade de Versões de Registros

Gabarito: letra B. No PostgreSQL, o controle de concorrência multiversão (MVCC) funciona criando snapshots consistentes: cada transação (ou instrução, dependendo do nível de isolamento) vê uma fotografia dos dados no momento do início, garantindo que leituras não bloqueiem escritas e que versões antigas sejam mantidas até que não sejam mais necessárias. A alternativa B descreve exatamente esse mecanismo: a consulta acessa um snapshot consistente no início de cada instrução SQL ou no início da transação, conforme o nível de isolamento (READ COMMITTED vs. REPEATABLE READ / SERIALIZABLE).

A questão testa o conhecimento sobre o comportamento do MVCC em relação à visibilidade de registros durante leituras. O PostgreSQL não utiliza bloqueios de leitura que bloqueiam escritas; em vez disso, mantém múltiplas versões de cada linha e usa o sistema de snapshots para decidir qual versão é visível para cada transação.

Alternativa A — ❌ Incorreta

Afirma que a leitura bloqueia automaticamente qualquer escrita concorrente. No MVCC, leitores nunca bloqueiam escritores e vice-versa. As escritas criam novas versões das linhas sem interferir nas leituras em andamento, que continuam vendo a versão anterior. Portanto, a afirmação é falsa.

Alternativa B — ✅ Correta ⟵ GABARITO

A alternativa está correta pois descreve o comportamento padrão do MVCC no PostgreSQL: um snapshot consistente é gerado no início de cada instrução SQL (no nível READ COMMITTED) ou no início da transação (nos níveis REPEATABLE READ e SERIALIZABLE). Esse snapshot determina quais versões dos registros são visíveis, garantindo que a consulta veja um estado coerente dos dados.

Alternativa C — ❌ Incorreta

Diz que a leitura falha caso haja uma escrita em andamento. No MVCC, leituras prosseguem normalmente mesmo se transações concorrentes estiverem escrevendo. A versão visível para a leitura é determinada pelo snapshot, e a escrita em andamento não interfere. Não há falha ou espera.

Alternativa D — ❌ Incorreta

Afirma que a leitura só pode acessar dados já confirmados por todas as transações concorrentes. Isso não é verdade no PostgreSQL: dependendo do nível de isolamento, uma leitura pode ver dados confirmados por transações que ainda não terminaram (mas já comitaram) ou até mesmo dados não confirmados se o nível for READ UNCOMMITTED (que no PostgreSQL é tratado como READ COMMITTED). Na prática, o PostgreSQL usa snapshots que evitam ler dados sujos, mas não espera que TODAS as transações concorrentes confirmem – apenas as que comitaram antes do snapshot.

Alternativa E — ❌ Incorreta

Afirma que durante uma leitura o SGBD pode acessar dados ainda não confirmados (dirty reads). O PostgreSQL não permite dirty reads em nenhum nível de isolamento padrão; ele trata READ UNCOMMITTED como READ COMMITTED. Portanto, leituras nunca veem dados não confirmados por outras transações.

Gabarito: letra B.