blog: tweak pg rollback

Author: tianzhou

content/blog/postgres-rollback.md

@@ -1,31 +1,34 @@
 ---
-title: 'PostgreSQL Rollback'
+title: 'Postgres Rollback Explained'
 author: Adela
 updated_at: 2025/09/04 18:00
 feature_image: /content/blog/postgres-rollback/cover.webp
 tags: Explanation
-description: 'An engineering perspective to evaluate PostgreSQL rollback strategies'
+description: 'An engineering perspective to evaluate Postgres rollback strategies'
 ---
 
-Database integrity and recovery mechanisms are critical for any production system. PostgreSQL provides multiple rollback strategies: built-in transaction rollback with SAVEPOINTs, Point-in-Time Recovery (PITR), and modern cross-transaction DML rollback solutions with tools. Each serves different use cases with distinct limitations.
+Database integrity and recovery mechanisms are critical for any production system. Postgres provides multiple rollback strategies: built-in transaction rollback with SAVEPOINT, Point-in-Time Recovery (PITR), and modern cross-transaction DML rollback solutions with tools. Each serves different use cases with distinct limitations.
 
-## Built-in Transaction Rollback and SAVEPOINTs
+## Built-in Transaction Rollback and SAVEPOINT
 
-PostgreSQL transactions allow rolling back all changes within a transaction block. For granular control, `SAVEPOINT`s create markers within transactions, enabling partial rollbacks without affecting earlier operations.
+Postgres transactions allow rolling back all changes within a transaction block. For granular control, `SAVEPOINT` create markers within transactions, enabling partial rollbacks without affecting earlier operations.
 
-### Using SAVEPOINTs
+### Using SAVEPOINT
 
 Create a savepoint:
+
 ```sql
 SAVEPOINT my_savepoint;
 ```
 
 Roll back to it:
+
 ```sql
 ROLLBACK TO SAVEPOINT my_savepoint;
 ```
 
 **Practical pattern for risky operations:**
+
 ```sql
 BEGIN;
 
@@ -56,16 +59,20 @@ The savepoint remains usable after rollback, but any savepoints created after it
 
 ## Point-In-Time Recovery (PITR)
 
-PITR restores databases to specific points in time using continuous WAL archiving. PostgreSQL's Write-Ahead Log records every database change. PITR combines base backups with archived WAL files to replay changes up to any desired moment.
+PITR restores databases to specific points in time using continuous WAL archiving. Postgres's Write-Ahead Log records every database change. PITR combines base backups with archived WAL files to replay changes up to any desired moment.
 
 ### Cloud Provider Support
+
 Major cloud providers offer one-click PITR experiences:
-- **AWS RDS for PostgreSQL**: Restore to point in time via Console/CLI/API
-- **Google Cloud SQL**: PITR from console interface  
-- **Azure Database for PostgreSQL**: Portal "Restore" to latest or chosen restore point
+
+- **AWS RDS for Postgres**: Restore to point in time via Console/CLI/API
+- **Google Cloud SQL**: PITR from console interface
+- **Azure Database for Postgres**: Portal "Restore" to latest or chosen restore point
 
 ### Named Restore Points
+
 Create targeted recovery points for easier PITR:
+
 ```sql
 -- Before risky migration
 SELECT pg_create_restore_point('pre_migration_2025_09_04');
@@ -74,10 +81,12 @@ SELECT pg_create_restore_point('pre_migration_2025_09_04');
 Later recover using `recovery_target_name = 'pre_migration_2025_09_04'` instead of guessing timestamps.
 
 ### Advantages
+
 - Handles any rollback scenario regardless of transaction commit status
 - Can recover from errors discovered hours or days later
 
 ### Limitations
+
 - Operates at cluster level - rolls back entire database, not individual tables or rows
 - Heavyweight operation unsuitable for small, isolated changes
 - Rolling back one incorrect `UPDATE` also undoes all subsequent valid changes
@@ -89,11 +98,13 @@ After a bad `UPDATE`/`DELETE`/`INSERT` is committed, you need **compensating DML
 ### Manual Compensating DML Example
 
 Accidentally ran:
+
 ```sql
 UPDATE accounts SET status = 'inactive' WHERE org_id = 42;
 ```
 
 Compensate using audit/history table:
+
 ```sql
 -- Revert to last known status per row
 UPDATE accounts a
@@ -113,13 +124,13 @@ Real systems must handle sequences, cascades, triggers, and side-effects.
 
 ### Bytebase Solution
 
-Bytebase provides point-and-click rollback through [Prior Backup](https://docs.bytebase.com/change-database/rollback-data-changes) functionality:
+Bytebase provides [point-and-click rollback](https://docs.bytebase.com/change-database/rollback-data-changes) functionality:
 
-1. **Prior Backup**: Automatically captures affected rows before DML execution
-2. **Change Execution**: Stores backup in dedicated `bbdataarchive` schema
-3. **1-Click Rollback**: Generates and executes rollback scripts automatically
+1. **Prior Backup**: Automatically captures affected rows before DML execution and stores in the dedicated `bbdataarchive` schema
+1. **1-Click Rollback**: Generates and executes rollback scripts automatically
 
 ### Workflow Benefits
+
 - Eliminates manual rollback script creation
 - Integrated review and approval process
 - Multi-task rollback across databases
@@ -129,23 +140,12 @@ Bytebase provides point-and-click rollback through [Prior Backup](https://docs.b
 
 Now that you understand the three rollback approaches, here's how to choose the right one for your situation:
 
-| Situation | Best Tool | Why |
-|-----------|-----------|-----|
-| Still in session, haven't committed | **Transaction rollback / SAVEPOINT** | Instant, lossless; keep good work, discard bad chunk |
-| Committed a small wrong UPDATE/DELETE | **Cross-transaction rollback (Bytebase)** | Surgical fix; no cluster restore |
-| Dropped table / mass data corruption | **PITR** | Ubiquitous, reliable; recovers to clean time point |
-| Need CREATE INDEX CONCURRENTLY | **Run outside explicit BEGIN** | PostgreSQL forbids it inside transaction block |
-| Need CREATE DATABASE | **Run autocommit / outside BEGIN** | Not allowed in transaction block |
-
-## Caveats & Gotchas
-
-- **Transaction abort state**: If a statement errors mid-transaction, the session is "aborted" until you `ROLLBACK`. Don't keep issuing statements hoping it heals.
-- **PITR blast radius**: It's cluster-level by design; plan to restore to a new server, verify state, then cut over or copy data back.
-- **Compensating DML complexity**: Manual rollback scripts are error-prone and must account for cascading effects, triggers, and referential integrity.
-
-
-## TL;DR
+| Situation                             | Best Tool                                 | Why                                                  |
+| ------------------------------------- | ----------------------------------------- | ---------------------------------------------------- |
+| Still in session, haven't committed   | **Transaction rollback / SAVEPOINT**      | Instant, lossless; keep good work, discard bad chunk |
+| Committed a small wrong UPDATE/DELETE | **Cross-transaction rollback (Bytebase)** | Surgical fix; no cluster restore                     |
+| Dropped table / mass data corruption  | **PITR**                                  | Ubiquitous, reliable; recovers to clean time point   |
 
 - **Use transactions + SAVEPOINT** to avoid mistakes in the first place
-- **Use PITR** when blast radius is unclear or damage is large - it's ubiquitous and cloud-friendly  
-- **Use compensating DML (or Bytebase's rollback workflow)** for small, precise fixes after commit - without PITR's weight
+- **Use PITR** when blast radius is unclear or damage is large - it's ubiquitous and cloud-friendly
+- **Use compensating DML (or Bytebase's rollback workflow)** for small, precise fixes after commit - without PITR's weight