PRAGMA AUTONOMOUS_TRANSACTION v14
An SPL program can be declared as an autonomous transaction by specifying the following directive in the declaration section of the SPL block. An autonomous transaction is an independent transaction started by a calling program.
A commit or rollback of SQL commands in the autonomous transaction has no effect on the commit or rollback in any transaction of the calling program. A commit or rollback in the calling program has no effect on the commit or rollback of SQL commands in the autonomous transaction.
The following SPL programs can include PRAGMA AUTONOMOUS_TRANSACTION
:
- Standalone procedures and functions
- Anonymous blocks
- Procedures and functions declared as subprograms in packages and other calling procedures, functions, and anonymous blocks
- Triggers
- Object type methods
The following are issues and restrictions related to autonomous transactions:
- Each autonomous transaction consumes a connection slot for as long as it's in progress. In some cases, this might mean that you need to raise the
max_connections
parameter in thepostgresql.conf
file. - In most respects, an autonomous transaction behaves as if it were a completely separate session, but GUCs (settings established with
SET
) are a deliberate exception. Autonomous transactions absorb the surrounding values and can propagate values they commit to the outer transaction. - Autonomous transactions can be nested, but there is a limit of 16 levels of autonomous transactions in a single session.
- Parallel query isn't supported in autonomous transactions.
- The EDB Postgres Advanced Server implementation of autonomous transactions isn't entirely compatible with Oracle databases. The EDB Postgres Advanced Server autonomous transaction doesn't produce an error if there's an uncommitted transaction at the end of an SPL block.
The following set of examples use autonomous transactions. This first set of scenarios shows the default behavior when there are no autonomous transactions.
Before each scenario, the dept
table is reset to the following initial values:
Scenario 1a: No autonomous transactions with only a final COMMIT
This first set of scenarios shows the insertion of three rows:
- Starting just after the initial
BEGIN
command of the transaction - From an anonymous block in the starting transactions
- From a stored procedure executed from the anonymous block
The stored procedure is the following:
The PSQL session is the following:
After the final commit, all three rows are inserted:
Scenario 1b: No autonomous transactions but a final ROLLBACK
The next scenario shows that a final ROLLBACK
command after all inserts results in the rollback of all three insertions:
Scenario 1c: No autonomous transactions, but anonymous block ROLLBACK
A ROLLBACK
command given at the end of the anonymous block also eliminates all three prior insertions:
The next set of scenarios shows the effect of using autonomous transactions with PRAGMA AUTONOMOUS_TRANSACTION
in various locations.
Scenario 2a: Autonomous transaction of anonymous block with COMMIT
The procedure remains as initially created:
The PRAGMA AUTONOMOUS_TRANSACTION
is given with the anonymous block along with the COMMIT
command at the end of the anonymous block:
After the ROLLBACK
at the end of the transaction, only the first row insertion at the beginning of the transaction is discarded. The other two row insertions in the anonymous block with PRAGMA AUTONOMOUS_TRANSACTION
were independently committed.