Undo Segments

Redrock Postgres maintains records of the actions of transactions, collectively known as undo data. Redrock Postgres uses undo data to do the following:

Roll back an active transaction
Recover a terminated transaction
Provide read consistency

Redrock Postgres stores undo data inside the database rather than in external logs. Undo data is stored in blocks that are updated just like data blocks, with changes to these blocks generating redo. In this way, Redrock Postgres can efficiently access undo data without needing to read external logs.

Undo data is stored in the pg_global tablespace. Redrock Postgres provides a fully automated mechanism, known as automatic undo segment management mode, for managing undo segments and space.

Undo Segments and Transactions

When a transaction starts, the database binds (assigns) the transaction to an undo segment, and therefore to a transaction table.

Multiple active transactions can write concurrently to the same undo or to different undo segments. For example, transactions T1 and T2 can both write to undo segment U1, or T1 can write to U1 while T2 writes to undo segment U2.

Conceptually, the extents in an undo segment form a ring. Transactions write to one undo extent, and then to the next extent in the ring, and so on in cyclical fashion. Figure 1 shows two transactions, T1 and T2, which begin writing in the third extent (E3) of an undo segment and continue writing to the fourth extent (E4).

Figure 1 Ring of Allocated Extents in an Undo Segment

At any given time, a transaction writes sequentially to only one extent in an undo segment, known as the current extent for the transaction. Multiple active transactions can write simultaneously to the same current extent or to different current extents. Figure 2 shows transactions T1 and T2 writing simultaneously to extent E3. Within an undo extent, a data block contains data for only one transaction.

As the current undo extent fills, the first transaction needing space checks the availability of the next allocated extent in the ring. If the next extent does not contain data from an active transaction, then this extent becomes the current extent. Now all transactions that need space can write to the new current extent. In Figure 2, when E4 is full, T1 and T2 continue writing to E1, overwriting the nonactive undo data in E1.

Figure 2 Cyclical Use of Allocated Extents in an Undo Segment

If the next extent does contain data from an active transaction, then the database must allocate a new extent. Figure 3 shows a scenario in which T1 and T2 are writing to E4. When E4 fills up, the transactions cannot continue writing to E1 because E1 contains active undo entries. Therefore, the database allocates a new extent (E5) for this undo segment. The transactions continue writing to E5.

Figure 3 Allocation of a New Extent for an Undo Segment

Transaction Rollback

When a ROLLBACK statement is issued, the database uses undo records to roll back changes made to the database by the uncommitted transaction. During recovery, the database rolls back any uncommitted changes applied from the online redo log to the data files. Undo records provide read consistency by maintaining the before image of the data for users accessing data at the same time that another user is changing it.

Manage Undo Segments

After the database instance data directory is initialized, 64 undo segments are generated in the database by default. To retrieve Information about existing undo segments in the current database, examine the pg_class system catalog, for example

SELECT oid, relname,
       pg_size_pretty(pg_relation_size(oid)) AS undsize
   FROM pg_class WHERE relkind = 'u';

When an undo segment used more than 1GB disk space, the background cleanup process will automatically shrink it to reclaim the unnecessary space it occupies.