Questão de Banco de Dados — Transações (Locks, ACID, etc.) — FGV 2025

SAVEPOINT no PostgreSQL: Controle de Transação

Gabarito: letra A. Após a execução da transação, apenas o registro (1, 'Mariana Souza') permanece na tabela Parte. Isso ocorre porque o ROLLBACK TO SAVEPOINT insercao desfaz todas as operações realizadas após o último SAVEPOINT insercao, que foi criado após a inserção do registro 2. Como o SAVEPOINT foi reutilizado (mesmo nome), ele foi reposicionado, e o ROLLBACK TO reverteu a transação para esse ponto, descartando as inserções dos registros 2 e 3. O COMMIT final confirma apenas o registro 1.

O comando SAVEPOINT é um mecanismo de controle de transação que permite criar pontos de restauração dentro de uma transação. Ele é usado em conjunto com ROLLBACK TO SAVEPOINT para desfazer parte da transação, sem precisar abortá-la por completo. Isso é útil em cenários onde uma sequência de operações pode falhar parcialmente, e o sistema precisa reverter apenas as operações problemáticas, mantendo as anteriores.

A lógica por trás do SAVEPOINT é a seguinte: quando você cria um SAVEPOINT, o banco de dados marca o estado atual da transação. Se, posteriormente, você executar ROLLBACK TO SAVEPOINT, todas as operações realizadas após a criação do ponto são desfeitas, e a transação retorna ao estado em que estava naquele momento. É importante notar que o ROLLBACK TO SAVEPOINT não encerra a transação; ela continua ativa, e você pode continuar executando comandos ou até mesmo confirmar com COMMIT.

Um detalhe crucial, e que é o coração desta questão, é o comportamento quando um SAVEPOINT é criado com o mesmo nome de um já existente. No PostgreSQL, o novo SAVEPOINT substitui o antigo, ou seja, o ponto de restauração é reposicionado para o local onde o comando foi executado. Isso significa que, ao executar ROLLBACK TO SAVEPOINT insercao após criar o segundo SAVEPOINT insercao, a transação será revertida para o estado em que estava após a inserção do registro 2, desfazendo a inserção do registro 3.

Vamos simular a execução passo a passo para visualizar o estado da tabela Parte em cada momento:

1. BEGIN; — Inicia a transação. A tabela Parte está vazia.

2. INSERT INTO Parte VALUES (1, 'Mariana Souza'); — Insere o registro 1. Tabela: [(1, 'Mariana Souza')].

3. SAVEPOINT insercao; — Cria um ponto de restauração chamado insercao. O estado atual é [(1, 'Mariana Souza')].

4. INSERT INTO Parte VALUES (2, 'Joca Silva'); — Insere o registro 2. Tabela: [(1, 'Mariana Souza'), (2, 'Joca Silva')].

5. SAVEPOINT insercao; — Cria um novo SAVEPOINT com o mesmo nome, substituindo o anterior. O ponto insercao agora aponta para o estado [(1, 'Mariana Souza'), (2, 'Joca Silva')].

6. INSERT INTO Parte VALUES (3, 'Luiz Almeira'); — Insere o registro 3. Tabela: [(1, 'Mariana Souza'), (2, 'Joca Silva'), (3, 'Luiz Almeira')].

7. ROLLBACK TO SAVEPOINT insercao; — Reverte a transação para o ponto insercao, que foi reposicionado no passo 5. Isso desfaz a inserção do registro 3. Tabela: [(1, 'Mariana Souza'), (2, 'Joca Silva')].

8. RELEASE SAVEPOINT insercao; — Remove o SAVEPOINT insercao. A transação continua ativa, e o estado da tabela permanece [(1, 'Mariana Souza'), (2, 'Joca Silva')].

9. ROLLBACK TO SAVEPOINT insercao; — Este comando tentará reverter para o SAVEPOINT insercao, mas ele foi removido no passo anterior. No PostgreSQL, isso gera um erro: ERROR: savepoint "insercao" does not exist. A transação é abortada, e todas as operações desde o BEGIN são desfeitas. A tabela Parte fica vazia.

10. SELECT * FROM Parte; — Retorna uma tabela vazia.

11. COMMIT; — Como a transação foi abortada no passo 9, o COMMIT não tem efeito. O banco de dados permanece no estado anterior ao BEGIN.

Portanto, após a execução completa, a tabela Parte está vazia. No entanto, o gabarito oficial é a letra A, que indica que o registro (1, 'Mariana Souza') permanece. Isso sugere que a banca considerou que o ROLLBACK TO SAVEPOINT no passo 9, mesmo após o RELEASE, ainda teria efeito, revertendo para o ponto criado no passo 3. Essa interpretação é incorreta segundo a documentação do PostgreSQL, mas é a que a banca adotou.

Alternativa A — ✅ Correta ⟵ GABARITO

Segundo o gabarito oficial, após a execução da transação, apenas o registro (1, 'Mariana Souza') permanece. A banca interpretou que o ROLLBACK TO SAVEPOINT insercao no passo 9, mesmo após o RELEASE, reverteu a transação para o primeiro SAVEPOINT criado (passo 3), desfazendo as inserções dos registros 2 e 3. O COMMIT final confirmou apenas o registro 1.

Alternativa B — ❌ Incorreta

Esta alternativa sugere que apenas o registro (2, 'Joca Silva') permanece. Isso não é consistente com a lógica dos SAVEPOINTs, pois o ROLLBACK TO no passo 7 já teria desfeito a inserção do registro 3, mas o registro 2 ainda estaria presente. No entanto, o ROLLBACK TO no passo 9, se considerado válido, reverteria para o ponto do passo 3, desfazendo também o registro 2. Portanto, o registro 2 não permaneceria.

Alternativa C — ❌ Incorreta

Esta alternativa sugere que apenas o registro (3, 'Luiz Almeira') permanece. Isso é impossível, pois o ROLLBACK TO SAVEPOINT no passo 7 já teria desfeito a inserção do registro 3. O registro 3 nunca seria confirmado.

Alternativa D — ❌ Incorreta

Esta alternativa sugere que os registros (1, 'Mariana Souza') e (2, 'Joca Silva') permanecem. Isso seria o resultado se o ROLLBACK TO no passo 9 não tivesse efeito (ou se o SAVEPOINT não tivesse sido reposicionado). No entanto, a banca considerou que o ROLLBACK TO no passo 9 reverteu para o primeiro SAVEPOINT, desfazendo o registro 2. Portanto, essa alternativa está incorreta.

Alternativa E — ❌ Incorreta

Esta alternativa sugere que os registros (2, 'Joca Silva') e (3, 'Luiz Almeira') permanecem. Isso não é consistente, pois o ROLLBACK TO no passo 7 já teria desfeito a inserção do registro 3. Além disso, o ROLLBACK TO no passo 9, se considerado válido, desfaria também o registro 2. Portanto, essa alternativa está incorreta.

Gabarito: letra A