ROLLBACK_TO_SAVEPOINT(7pg16)

✨ ROLLBACK TO SAVEPOINT 💅

okay so this is the <pink>ROLLBACK TO SAVEPOINT</pink> page from the <purple>PostgreSQL 16.15</purple> docs, bestie — it's a <lavender>7</lavender>-section manual page and honestly it's kind of a hero. it's the "undo button but make it transactional" moment, and you're gonna love it. 🎀

---

🌸 NAME 🌸

ROLLBACK_TO_SAVEPOINT — roll back to a savepoint. literally what it says on the tin. 🫶

---

🦋 SYNOPSIS 🦋

ROLLBACK [ WORK | TRANSACTION ] TO [ SAVEPOINT ] savepoint_name

look at her. optional noise words, optional SAVEPOINT, one very important name. iconic. ✨

---

💖 DESCRIPTION 💖

so here's the vibe: <pink>ROLLBACK TO SAVEPOINT</pink> 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. no cap. 💅

and the best part? the savepoint stays valid — like, she's still there, still cute — so you can roll back to her again later if you need to. obsessed. 🧚

one thing you gotta know though (and this is important, fr fr): ROLLBACK TO SAVEPOINT implicitly destroys every savepoint that was established after the named savepoint. gone. not coming back. 💀

---

🎀 PARAMETERS 🎀

• savepoint_name — the savepoint to roll back to. that's it. that's the parameter. the main character. 👑

---

⭐ NOTES ⭐

• use <mint>RELEASE SAVEPOINT</mint> when you wanna destroy a savepoint without throwing away the effects of the commands executed after it was established. different energy, different command. 🔥
• specifying a savepoint name that has not been established is an error. it's giving "who? never met her." 🙈
• k so cursors have "somewhat non-transactional behavior" with respect to savepoints, which is the most lowkey ominous way to phrase that, honestly:
  • 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 gets rolled back later, the cursor remains at the position that FETCH left it pointing to — that is, the cursor motion caused by FETCH is not rolled back. 😭
  • closing a cursor is not undone by rolling back either. nope. 🍓
  • 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. 🌈
  • and if a cursor whose execution causes a transaction to abort, that cursor 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. she's done. retired. 💅

like, the transaction gets better but the cursor does not. that's the tea. 🫖

---

🧚 EXAMPLES 🧚

to undo the effects of the commands executed after my_savepoint was established:

ROLLBACK TO SAVEPOINT my_savepoint;

cursor positions are not affected by savepoint rollback — watch her go:

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 FETCH came back 2 and not 1? yeah. that's the whole thing. slay. 👑

---

💜 COMPATIBILITY 💜

so the SQL standard specifies that the key word SAVEPOINT is mandatory, but <pink>PostgreSQL</pink> and <peach>Oracle</peach> allow it to be omitted. we're flexible like that. ✨

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

also, SQL has an optional clause AND [ NO ] CHAIN which is not currently supported by PostgreSQL. so don't come for her about that one. 🙈

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 page, bestie 🫶 this was the <rainbow>PostgreSQL 16.15</rainbow> docs, dated <yellow>2026</yellow>, and the page is <hotpink>ROLLBACK TO SAVEPOINT(7)</hotpink> — go forth and savepoint responsibly. 💖✨🎀