ROLLBACK_TO_SAVEPOINT(7pg14)

✨ ROLLBACK TO SAVEPOINT ✨

okay so bestie, we're in the PostgreSQL 14.24 documentation and this little icon is literally the "undo" button for your savepoints 💅 stay with me, it's so good.

---

🌸 NAME 🌸

ROLLBACK_TO_SAVEPOINT — roll back to a savepoint 🎀

---

🦋 SYNOPSIS 🦋

ROLLBACK [ WORK | TRANSACTION ] TO [ SAVEPOINT ] savepoint_name

look at that. so clean. so iconic. ✨

---

💖 DESCRIPTION 💖

So here's the vibe: ROLLBACK TO SAVEPOINT rolls back all the commands that were executed after the savepoint was established. every single one. gone. 💀

But — and this is the main character detail — the savepoint itself remains valid and you can roll back to it again later if you need to. it's not going anywhere, it's just sitting there being helpful 🫶

Also, ROLLBACK TO SAVEPOINT implicitly destroys all savepoints that were established after the named savepoint. so any savepoints you made downstream of it? poof. not sorry 🙈

---

🎀 PARAMETERS 🎀

• savepoint_name — the savepoint to roll back to. that's it. that's the whole parameter. queen behavior honestly 👑

---

🧚 NOTES 🧚

• Use RELEASE SAVEPOINT to destroy a savepoint without discarding the effects of commands executed after it was established. different tool, different job, iykyk ✨
• Specifying a savepoint name that has not been established is an error. so don't do that 💀

Okay now the cursor part, and ngl this is the part where you gotta pay attention because cursors are lowkey non-transactional when it comes to savepoints 😭 let me break it down:

• Any cursor that is opened inside a savepoint will be closed when the savepoint is rolled back.
• If a previously opened cursor is affected by a FETCH or MOVE command inside a savepoint that is later rolled back, the cursor remains at the position that FETCH left it pointing to — that is, the cursor motion caused by FETCH is not rolled back. the cursor said "i'm staying right here" 🪑
• Closing a cursor is not undone by rolling back, either.
• However, other side-effects caused by the cursor's query (such as side-effects of volatile functions called by the query) are rolled back if they occur during a savepoint that is later rolled back.
• A cursor whose execution causes a transaction to abort is put in a cannot-execute state. so while the transaction can be restored using ROLLBACK TO SAVEPOINT, the cursor can no longer be used. tragic. but like, accurate 💀

fr fr bestie, read the cursor rules twice. they will humble you.

---

🔥 EXAMPLES 🔥

Wanna undo the effects of the commands executed after my_savepoint was established? slay, here you go:

ROLLBACK TO SAVEPOINT my_savepoint;

And here's the glow-up that proves cursor positions are not affected by savepoint rollback 👑

BEGIN;

DECLARE foo CURSOR FOR SELECT 1 UNION SELECT 2;

SAVEPOINT foo;

FETCH 1 FROM foo;
 ?column?
----------
        1

ROLLBACK TO SAVEPOINT foo;

FETCH 1 FROM foo;
 ?column?
----------
        2

COMMIT;

see how the second FETCH gives you 2? that's the cursor just... continuing. no cap. 🌈

---

⭐ COMPATIBILITY ⭐

So the SQL standard specifies that the key word SAVEPOINT is mandatory — but PostgreSQL and Oracle allow it to be omitted. we're flexible like that 💅

SQL allows only WORK, not TRANSACTION, as a noise word after ROLLBACK. Also, SQL has an optional clause AND [ NO ] CHAIN which is not currently supported by PostgreSQL. 🙈

Otherwise? this command conforms to the SQL standard. periodt. ✨

---

💜 SEE ALSO 💜

• BEGIN(7)
• COMMIT(7)
• RELEASE SAVEPOINT (RELEASE_SAVEPOINT(7))
• ROLLBACK(7)
• SAVEPOINT(7)

---

and that's the whole page bestie! 🌸💖🎀🦋 this was PostgreSQL 14.24, dated 2026, and honestly? go forth and roll back responsibly ✨🫶