ROLLBACK_TO_SAVEPOINT(7pg18)

✨ ROLLBACK TO SAVEPOINT ✨

ok so bestie, this is the PostgreSQL 18.6 Documentation page for ROLLBACK TO SAVEPOINT(7) and it's literally the "undo button but make it surgical" of the SQL world 💅

---

🌸 NAME 🌸

ROLLBACK_TO_SAVEPOINT — roll back to a savepoint 🎀

---

🦋 SYNOPSIS 🦋

ROLLBACK [ WORK | TRANSACTION ] TO [ SAVEPOINT ] savepoint_name

---

💖 DESCRIPTION 💖

okay so here's the tea ☕ — this command rolls back all the commands that were executed after the savepoint was established, and then it starts a brand new subtransaction at the same transaction level. it's giving "rewind, but we're still standing" ✨

and the best part? the savepoint remains valid and you can roll back to it again later if you need to. it's not a one-time thing, it's a forever safe space 🫶

but heads up: ROLLBACK TO SAVEPOINT implicitly destroys all savepoints that were established after the named savepoint. no cap. they're gone, bestie 💀

---

🎀 PARAMETERS 🎀

• savepoint_name — the savepoint you're rolling back to. that's it, that's the whole parameter 🍓

---

🌈 NOTES 🌈

• use RELEASE SAVEPOINT when you wanna destroy a savepoint without discarding the effects of the commands executed after it was established. different vibe, different purpose, iykyk ✨
• specifying a savepoint name that has not been established is an error. it's not gonna be like "sure bestie, close enough" — it's gonna yell at you 😭
• cursors have somewhat non-transactional behavior with respect to savepoints, and honestly this is the part everyone gets confused about, so listen up 👑:
  • 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. translation: the cursor motion caused by FETCH is not rolled back. it just… stays. main character energy, refuses to be undone 💅
  • closing a cursor is not undone by rolling back either. nope.
  • however, other side-effects caused by the cursor's query (like side-effects of volatile functions called by the query) are rolled back if they occur during a savepoint that is later rolled back. so it's a whole mix, bestie 🦋
  • 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. rip cursor 🪦

---

✨ EXAMPLES ✨

want to undo the effects of the commands executed after my_savepoint was established? say less:

ROLLBACK TO SAVEPOINT my_savepoint;

and here's the iconic one showing that cursor positions are not affected by savepoint rollback — watch the number change from 1 to 2 after the rollback, because the FETCH motion literally does not get undone 😭🔥

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;

---

💜 COMPATIBILITY 💜

ok so the SQL standard says the key word SAVEPOINT is mandatory, but PostgreSQL and Oracle are the chill ones and allow it to be omitted 🫶

SQL also allows only WORK, not TRANSACTION, as a noise word after ROLLBACK. noted 📝

and SQL has an optional clause AND [ NO ] CHAIN which is not currently supported by PostgreSQL. so don't try it, bestie 💀

otherwise? this command conforms to the SQL standard. slay 👑

---

🌟 SEE ALSO 🌟

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

---

and that's the whole page, babe 🎀 this was ROLLBACK TO SAVEPOINT(7) from the PostgreSQL 18.6 docs, dated 2026 — go forth and roll back responsibly, you absolute icon 👑💖✨