Transactions are an important feature in any database. We want to be "ACID Compliant" and ensure that all data is read and written in a consistent state. All changes in the transaction either commit or rollback together. You never change just one table, without also changing all the other related tables together in an atomic block.

But what about when you actually want to change just one table and roll back all the rest? Or you have to ensure that one change is made whether or not the rest of the transaction is committed? Maybe you need to write an audit record of an attempted change or data access by a user.

As a database developer, you want these sub-transactions or autonomous transactions to be processed and committed regardless of what happens to the larger surrounding transaction block. The application could open 2 connections or make 2 transactions in a row, but if the 2nd transaction or connection failed you might not get your audit record written, and you would be paying a performance penalty.

If you’re coming from an Oracle background, you may be familiar with PRAGMA AUTONOMOUS TRANSACTION – which makes a procedure execute in an autonomous transaction so any changes in the procedure are committed separately from the calling PL/SQL code.

PostgreSQL Enterprise Serverprovides support for autonomous transactions through isolated worker processes that execute SQL statements in a separate transaction from the calling transaction. Autonomous transactions can be executed syncronously or asynchronously. Asynchronous autonomous transactions to prevent the execution from blocking the main transaction, while synchronous autonomous transactions will block the main thread until completion.