RELEASE_SAVEPOINT(7pg17)

okay bestie, welcome to the PostgreSQL 17.11 Documentation glow-up of RELEASE SAVEPOINT(7) 💅✨ this one is literally about letting go of a savepoint the right way, and yes, the details matter fr fr.

---

💖 NAME 💖

RELEASE_SAVEPOINT — release a previously defined savepoint. that's the whole assignment, bestie 🎀

✨ SYNOPSIS ✨

RELEASE [ SAVEPOINT ] savepoint_name

🌸 DESCRIPTION 🌸

RELEASE SAVEPOINT releases the named savepoint and all active savepoints that were created after the named savepoint, and it frees their resources. very cleanup, very demure ✨

All changes made since the savepoint was created that didn’t already get rolled back are merged into the transaction or savepoint that was active when the named savepoint was created. and anything you do after RELEASE SAVEPOINT will also be part of that active transaction or savepoint. no cap, it all folds back into the same vibe 💜

🎀 PARAMETERS 🎀

• savepoint_name — the name of the savepoint to release. that’s the one you’re sending off 🫶

🦋 NOTES 🦋

• Specifying a savepoint name that was not previously defined is an error. so don’t try to release a savepoint that never existed, bestie 😭
• It is not possible to release a savepoint when the transaction is in an aborted state; to do that, use ROLLBACK TO SAVEPOINT (ROLLBACK_TO_SAVEPOINT(7)). that’s the move for aborted-state business 💅
• If multiple savepoints have the same name, only the most recently defined unreleased one is released. Repeated commands will release progressively older savepoints. so yes, same-name savepoints get handled newest-first, then older ones as you keep going ⭐

🔥 EXAMPLES 🔥

To establish and later release a savepoint:

       BEGIN;
           INSERT INTO table1 VALUES (3);
           SAVEPOINT my_savepoint;
           INSERT INTO table1 VALUES (4);
           RELEASE SAVEPOINT my_savepoint;
       COMMIT;

The above transaction will insert both 3 and 4. iconic behavior, honestly 👑

A more complex example with multiple nested subtransactions:

       BEGIN;
           INSERT INTO table1 VALUES (1);
           SAVEPOINT sp1;
           INSERT INTO table1 VALUES (2);
           SAVEPOINT sp2;
           INSERT INTO table1 VALUES (3);
           RELEASE SAVEPOINT sp2;
           INSERT INTO table1 VALUES (4))); -- generates an error

In this example, the application requests the release of the savepoint sp2, which inserted 3. This changes the insert’s transaction context to sp1. When the statement attempting to insert value 4 generates an error, the insertion of 2 and 4 are lost because they are in the same, now-rolled back savepoint, and value 3 is in the same transaction context. The application can now only choose one of these two commands, since all other commands will be ignored:

           ROLLBACK;
           ROLLBACK TO SAVEPOINT sp1;

Choosing ROLLBACK will abort everything, including value 1, whereas ROLLBACK TO SAVEPOINT sp1 will retain value 1 and allow the transaction to continue. choose wisely, bestie 😭💀

🌈 COMPATIBILITY 🌈

This command conforms to the SQL standard. The standard specifies that the key word SAVEPOINT is mandatory, but PostgreSQL allows it to be omitted. slay for flexibility 💅

👑 SEE ALSO 👑

• BEGIN(7)
• COMMIT(7)
• ROLLBACK(7)
• ROLLBACK TO SAVEPOINT (ROLLBACK_TO_SAVEPOINT(7))
• SAVEPOINT(7)

---

byeee bestie 🫶 — this glow-up came from PostgreSQL 17.11, dated 2026, for RELEASE SAVEPOINT(7). 💅✨