14TransactionsInOracle

Transaction Processing in PostgreSQL DBMS

Outline

Transaction scope
Isolation levels in PostgreSQL
READ COMMITTED isolation level
REPEATABLE READ isolation level (SI)
SERIALIZABLE isolation level (SSI)

This presentation addresses transaction processing in PostgreSQL system and in particular isolation level available for transaction processing in the system.

A scope of transaction in PostgreSQL is determined by BEGIN or STRAT TRANSACTION statements and COMMIT or ROLLBACK statements.

The statements BEGIN, START TRANSACTION start a transaction and the statements COMMIT and ROLLBACK end a transaction.

A single SQL statement processed outside explicitly determined transaction borders become a single-statement transaction.

Some of data definition language statements, e.g CREATE/DROP/ALTER TABLE/INDEX etc are included in the transactional DLL. It means that such DLL statements are reversible with ROLLBACK statement.

DDL statements like CREATE/DROP/ALTER DATABASE/TABLESPACE/CLUSTER are not reversible.

If a processing error occurs in a running transaction then the transaction is aborted and automatically rolled back.

Still a statement like COMMIT, ROLLBACK, ABORT is still required to complete the current transaction.

Transaction scope

A transaction starts from BEGIN or START TRANSACTION statement and it ends with COMMIT or ROLLBACK statement
SQL statements outside of an explicit transaction automatically become a single-statement transaction
PostgreSQL supports transactional DDL
It means that all DDL statemehts except CREATE/DROP/ALTER DATABASE, TABLESPACE, CLUSTER are reversible
If an error occurs inside a transaction then it is automatically rolledback
However, still a statement to complete the current transaction (COMMIT, ROLLBACK, ABORT) is required

Transaction Processing in PostgreSQL DBMS

Isolation levels in PostgreSQL

At READ COMMITED isolation level a transaction may exhibit:
- non-repeatable read phenomenon,
- phantom phenomenon
At REPEATABLE READ isolation level (SI) a transaction may exhibit:
- other phonemena (write skew)
At SERIALIZABLE isolation level (SSI)a transaction may exhibit:
- none of the phenomena

	      
Level           Dirty Read    Nonrepeatable Read  Phantom       Other (Write skew)
----------------------------------------------------------------------------------	      
READ COMMITTED  Not possible  Possible            Possible      Possible

REPEATABLE READ Not possible  Not possible        Not possible  Possible

SERIALIZABLE    Not possible  Not possible        Not possible  Not possible

Transaction Processing in PostgreSQL DBMS

Outline

Transaction scope
Isolation levels in PostgreSQL
READ COMMITTED isolation level
REPEATABLE READ isolation level (SI)
SERIALIZABLE isolation level (SSI)

READ COMMITTED isolation level

We consider a database created through processing of the following CREATE TABLE statements

     
CREATE TABLE DEPARTMENT(
 name               VARCHAR(50)        NOT NULL,
 code               CHAR(5)            NOT NULL,
 total_staff_number DECIMAL(2)         NOT NULL,
 chair              VARCHAR(50)            NULL,
 budget             DECIMAL(9,1)       NOT NULL,
  CONSTRAINT dept_pkey PRIMARY KEY(name),
  CONSTRAINT dept_ckey1 UNIQUE(code),
  CONSTRAINT dept_ckey2 UNIQUE(chair),
  CONSTRAINT dept_check1 CHECK (total_staff_number BETWEEN 1 AND 50) );

     
CREATE TABLE COURSE(
 cnum               CHAR(7)           NOT NULL,
 title              VARCHAR(200)      NOT NULL,
 credits            DECIMAL(2)        NOT NULL,
 offered_by         VARCHAR(50)           NULL,
  CONSTRAINT course_pkey PRIMARY KEY(cnum),
  CONSTRAINT course_check1 CHECK (credits IN (6, 12)),
  CONSTRAINT course_fkey1 FOREIGN KEY(offered_by)
                          REFERENCES DEPARTMENT(name) ON DELETE CASCADE );

READ COMMITTED isolation level

Dirty read is not possible

     
BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT title FROM COURSE WHERE cnum='CSCI111';
 title
-------
 C++

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
                            UPDATE COURSE SET title = 'Java' WHERE cnum='CSCI111';

     
SELECT title FROM COURSE WHERE cnum='CSCI111';
 title
-------
C++

     
                            COMMIT;

The lost update is not possible at READ COMMITTED isolation level.

the first transaction selects a budget of Computer Science department with

SELECT budget FROM DEPARTMENT WHERE name = 'Computer Science';

Next, the first transaction increase a budget of Computer Science department by 100 with

UPDATE DEPARTMENT SET budget = budget + 100 WHERE name = 'Computer Science';

Then, the second transaction starts and it attempts increase a budget of Computer Science department by 200 with

UPDATE DEPARTMENT SET budget = budget + 200 WHERE name = 'Computer Science';

The second transaction cannot see a modification performed by the first transaction because such modification is not committed yet.

On the other hand an update of an old version of data item makes no sense because if both transactions commit their updates we are left with two versions of a data item and a problem is which one is correct.

It is why the second transaction must wait for commit or rollback performed by the first transaction.

The concurrent processing is continued on the next slide.

READ COMMITTED isolation level

Lost update is not possible

     
BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT budget FROM DEPARTMENT
WHERE name = 'Computer Science';
  budget  
----------
 223426.9

UPDATE DEPARTMENT SET budget = budget + 100
WHERE name = 'Computer Science';

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
                            UPDATE DEPARTMENT SET budget = budget + 200
                            WHERE name = 'Computer Science';
                            WAIT !!!

Continued on the next slide ...

READ COMMITTED isolation level

Continuation from the previous slide ...

     
COMMIT;

     
                             COMMIT;

SELECT budget from DEPARTMENT
WHERE name = 'Computer Science';
  budget  
----------
 223726.9

Non-repeatable read phenomenon is possible at READ COMMITTED isolation level.

The first transaction retrieves a budget of Computer Science department with

SELECT budget FROM DEPARTMENT WHERE name = 'Computer Science';

The second transaction increases the budget by 200 with

UPDATE DEPARTMENT SET budget = budget + 200 WHERE name = 'Computer Science';

And then it immediately commits the update.

The first transaction again retrieves a budget of Computer Science department with

SELECT budget FROM DEPARTMENT WHERE name = 'Computer Science';

The budget is increased 223426.9 + 200 = 223626.9

The first transaction can ''see'' updated value because update performed by the second transaction is committed and the first transaction runs at READ COMMITTED isolation level.

READ COMMITTED isolation level

Non-repeatable read phenomenon is possible

BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT budget FROM DEPARTMENT
WHERE name = 'Computer Science';
  budget  
----------
 223426.9

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
                            UPDATE DEPARTMENT SET budget = budget + 200
                            WHERE name = 'Computer Science';

                            COMMIT;

SELECT budget FROM DEPARTMENT
WHERE name = 'Computer Science';
  budget  
----------
 223626.9

Phantom phenomenon is also possible at READ COMMITTED isolation level.

The first transaction counts the total number of courses available with

SELECT count(*) FROM COURSE;

The total number of courses is 15.

The second transaction removes all courses offered by Mathematics department with

DELETE FROM COURSE WHERE offered_by = 'Mathematics';

And it immediately commits the deletion.

Then, the second transaction counts the total number of courses available with

SELECT count(*) FROM COURSE;

The second transaction can ''see'' the outcomes of deletion performed by the first transaction because the second transaction committed its deletion.

Hence, consecutive counting of the rows by the first transaction returns different results, i.e. a ''phantom row'' that disappeared from the results of the second count.

READ COMMITTED isolation level

Phantom phenomenon is possible

BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT count(*) FROM COURSE;
 count
-------
    15

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
                            DELETE FROM COURSE
                            WHERE offered_by = 'Mathematics';

                            COMMIT;

SELECT count(*) FROM COURSE;
 count
-------
    14

Corruption of a database by the concurrently running transactions at READ COMMITTED level is also possible.

An objective of data manipulation operation is to increase a budget of Computer Science department to a value equal to 2*budget of Mathematics department.

The first transaction retrieves the budgets of Computer Science and mathematics departments with

SELECT name, budget FROM DEPARTMENT WHERE name IN ('Computer Science','Mathematics');

Next, the same transaction updates a budget of Computer Science department to a value equal to a budget of Mathematics department with the following nested update statement.

UPDATE DEPARTMENT SET budget = (SELECT budget FROM DEPARTMENT WHERE name = 'Mathematics') WHERE name = 'Computer Science';

The processing continues on the next slide.

READ COMMITTED isolation level

Corruption of a database is possible

We would like to set a budget of Computer Science department equal to 2*budget of Mathematics department

BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT name,budget FROM DEPARTMENT
WHERE name IN ('Computer Science','Mathematics');
       name       |  budget  
------------------+----------
 Computer Science | 223426.9
 Mathematics      | 133456.9

  
UPDATE DEPARTMENT SET budget =
       (SELECT budget FROM DEPARTMENT
        WHERE name = 'Mathematics')
WHERE name = 'Computer Science';

Continued on the next slide ...

Next, the second transaction updates a budget of Mathematic department adding 1000 to the budget.

UPDATE DEPARTMENT SET BUDGET = 1000 WHERE name = 'Mathematics';

and commits its operations.

It means that a budget of mathematics department changed from 133456.9 to 1000 and such update has been successfully committed.

Now, the first transaction increase a budget of Computer Science department adding a new budget of Mathematics department to the old budget of Mathematics department with

UPDATE DEPARTMENT SET budget = budget + (SELECT budget FROM DEPARTMENT WHERE name = 'Mathematics') WHERE name = 'Computer Science';

The first transaction is able to access a new budget of Mathematics department because such value was committed by the second transaction and the first transaction runs at READ COMMITTED isolation level.

Obviously, after such processing a budget of Computer Science department is not equal to 2* budget of Mathematic department. Such conclusion is confirmed with

SELECT name, budget FROM DEPARTMENT WHERE name IN ('Computer Science','Mathematics');

The present budget of Computer Science department is equal to 133456.9 + 1000 = 134456.9. It measn that the first transaction failed to increase a budget in a required way.

READ COMMITTED isolation level

Continued from the previous slide ...

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
			    UPDATE DEPARTMENT SET BUDGET = 1000
			    WHERE name = 'Mathematics';

                            COMMIT;

  
UPDATE DEPARTMENT SET budget =  budget +
       (SELECT budget FROM DEPARTMENT
        WHERE name = 'Mathematics')
WHERE name = 'Computer Science';

SELECT name,budget FROM DEPARTMENT
WHERE name IN ('Computer Science','Mathematics');
       name       |  budget  
------------------+----------
 Mathematics      |   1000.0
 Computer Science | 134456.9

READ COMMITTED isolation level

Write skew is possible

We would like to remove one of the courses, either ENGG100 or ENGG103

BEGIN;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';
  cnum   |               title                
---------+------------------------------------
 ENGG103 | Materials in Design
 ENGG100 | Engineering Computing and Analysis
 ENGG111 | C++

  
DELETE FROM COURSE WHERE cnum = 'ENGG103';

Continued on the next slide ...

The second transaction lists all course whose code starts from ENGG.

SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';

Both courses ENGG100 and ENGG103 are listed because deletion of ENGG103 performed by the first transaction a moment earlier is not committed yet. it is why the second transaction operates on the old versions of the rows included in COURSE table.

The outcomes from SELECT statement convince the second transaction that none of ENGG100 or ENGG103. is deleted yet. It is why the second transaction deletes ENGG100 with

DELETE FROM COURSE WHERE cnum = 'ENGG100';

Then both transactions commit their action.

SELECT statement

SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';

shows that both ENGG100 and ENGG103 are deleted and an objective was to delete only one of them.

It shows a write skew phenomenon and corruption of a database.

READ COMMITTED isolation level

Continued from the previous slide ...

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
			    SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';
                              cnum   |               title                
                            ---------+------------------------------------
                             ENGG103 | Materials in Design
                             ENGG100 | Engineering Computing and Analysis
                             ENGG111 | C++

  
	                     DELETE FROM COURSE WHERE cnum = 'ENGG100';

COMMIT;

                             COMMIT;

SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';
  cnum   |               title                
---------+------------------------------------
 ENGG111 | C++

Transaction Processing in PostgreSQL DBMS

Outline

Transaction scope
Isolation levels in PostgreSQL
READ COMMITTED isolation level
REPEATABLE READ isolation level (SI)
SERIALIZABLE isolation level (SSI)

A non-repeatable read phenomenon is not possible when a transaction runs at REPEATABLE READ isolation level.

We consider the following concurrent processing of database transactions running at REPEATABLE READ isolation level.

The first transaction list a budget of Computer Science department with

SELECT budget FROM DEPARTMENT WHERE name = 'Computer Science';

The second transaction increases a budget of Computer Science department by 200 with

UPDATE DEPARTMENT SET budget = budget + 200 WHERE name = 'Computer Science';

And it commits the update. A new version of a row with an updated budget of Computer Science department is added to a table DEPARTMENT.

The first transaction lists again a budget of Computer Science department with

SELECT budget FROM DEPARTMENT WHERE name = 'Computer Science';

A value obtained by the first transaction is the same as a value obtained from the first SELECT statement despite a committed update performed by the second transaction. It is because the first transaction still has access to the old version of a row with a budget of Computer Science department.

The present concurrent processing shows that non-repeatable read is not possible because transaction can always access old version of an update data item.

REPEATABLE READ isolation level (SI)

Non-repeatable read phenomenon is not possible

BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT budget FROM DEPARTMENT
WHERE name = 'Computer Science';
  budget  
----------
 223426.9

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
                            UPDATE DEPARTMENT SET budget = budget + 200
                            WHERE name = 'Computer Science';

                            COMMIT;

SELECT budget FROM DEPARTMENT
WHERE name = 'Computer Science';
  budget  
----------
 223426.9

When a transaction is processed at REPEATABLE READ isolation level phantom phenomenon is not possible.

To prove it we consider the following processing of database transactions at REPEATABLE READ isolation level.

The first transaction counts the total number of courses with

SELECT count(*) FROM COURSE;

The second transaction removes all courses offred by a department of Mathematics with

DELETE FROM COURSE WHERE offered_by = 'Mathematics';

The second transaction commits the deletions.

The first transaction again counts the total number of courses with

SELECT count(*) FROM COURSE;

and the result is the same as before. It is because the old versions of the rows representing the courses offered by Mathematics department are still in COURSE table.

REPEATABLE READ isolation level (SI)

Phantom phenomenon is not possible

BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT count(*) FROM COURSE;
 count
-------
    15

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
                            DELETE FROM COURSE
                            WHERE offered_by = 'Mathematics';

                            COMMIT;

SELECT count(*) FROM COURSE;
 count
-------
    15

REPEATABLE READ isolation level (SI)

Corruption of a database is not possible

We would like to set a budget of Computer Science department equal to 2*budget of Mathematics department

BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT name,budget FROM DEPARTMENT
WHERE name IN ('Computer Science','Mathematics');
       name       |  budget  
------------------+----------
 Computer Science | 223426.9
 Mathematics      | 133456.9

  
UPDATE DEPARTMENT SET budget =
       (SELECT budget FROM DEPARTMENT
        WHERE name = 'Mathematics')
WHERE name = 'Computer Science';

Continued on the next slide ...

The second transaction changes a budget of mathematics department to 100 with the following UPDATE statememt.

UPDATE DEPARTMENT SET BUDGET = 1000 WHERE name = 'Mathematics';

A new version of a row that contains information about Mathematics department is created. A value of budget in the new row is equal to 1000.

The second transaction commits the update.

Next, the first transaction attempt to increase a budget of Computer Science department by adding a budget of Mathematics department to the current value of Computer Science budget.

UPDATE DEPARTMENT SET budget = budget + (SELECT budget FROM DEPARTMENT WHERE name = 'Mathematics') WHERE name = 'Computer Science';

If the first transaction would run at READ COMMITTED level such operation would not work all right due to different values of Mathematics budget.

In the present case, the first transaction runs at REPEATABLE READ isolation level and it reads old version of Mathematics budget.

Hence the result listed with

SELECT name, budget FROM DEPARTMENT WHERE name IN ('Computer Science','Mathematics');

is equal to 266913.8 = 2 * 133456.9

It means that in such a case corruption of a database is not possible.

REPEATABLE READ isolation level

Continued from the previous slide ...

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
			    UPDATE DEPARTMENT SET BUDGET = 1000
			    WHERE name = 'Mathematics';

                            COMMIT;

  
UPDATE DEPARTMENT SET budget =  budget +
       (SELECT budget FROM DEPARTMENT
        WHERE name = 'Mathematics')
WHERE name = 'Computer Science';

SELECT name,budget FROM DEPARTMENT
WHERE name IN ('Computer Science','Mathematics');
       name       |  budget  
------------------+----------
 Mathematics      |   1000.0
 Computer Science | 266913.8

Lost update is also not possible at REPEATABLE READ isolation level.

The first transaction lists a budget of Computer Science department with

SELECT budget FROM DEPARTMENT WHERE name = 'Computer Science';

Next, the first transaction increases a budget of Computer Science department by 100 with the following UPDATE statement.

UPDATE DEPARTMENT SET budget = budget + 100 WHERE name = 'Computer Science';

Then, the second transaction attempts to increase a budget of Computer Science department by 200 with

UPDATE DEPARTMENT SET budget = budget + 200 WHERE name = 'Computer Science';

Such update cannot be processed because The second transaction must wait for either COMMIT or ROLLBACK performed by the first transaction.

Otherwise, an update processed by the second transaction can use two different version of budget, either old one before update of the first transaction or new after an update performed by the first transaction.

So everything depends on wether the first transaction commits or rollbacks its update and the second transaction must wait for the oucomes from the first transaction.

The processing continues on the next slide.

REPEATABLE READ isolation level

Lost update is not possible (first committer wins)

     
BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
SELECT budget FROM DEPARTMENT
WHERE name = 'Computer Science';
  budget  
----------
 223426.9

UPDATE DEPARTMENT SET budget = budget + 100
WHERE name = 'Computer Science';

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
                            UPDATE DEPARTMENT SET budget = budget + 200
                            WHERE name = 'Computer Science';
                            WAIT !!!

Continued on the next slide ...

REPEATABLE READ isolation level

Continuation from the previous slide ...

     
COMMIT;

     
                      ERROR:  could not serialize access due to concurrent update

SELECT budget from DEPARTMENT
WHERE name = 'Computer Science';
  budget  
----------
 223526.9

REPEATABLE READ isolation level

Write skew is possible

We would like to remove one of the courses, either ENGG100 or ENGG103

BEGIN;
SET TRANSACTION ISOLATION LEVEL REPATABLE READ;
SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';
  cnum   |               title                
---------+------------------------------------
 ENGG103 | Materials in Design
 ENGG100 | Engineering Computing and Analysis
 ENGG111 | C++

  
DELETE FROM COURSE WHERE cnum = 'ENGG103';

Continued on the next slide ...

The second transaction list the course that have a code starting from ENGG with the following SELECT statement.

SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';

The system displays a course ENGG103 because deletion performed by the first transaction is not committed yet.

The second transaction is not aware of the deleteion perfromed by the first transaction and it removes a course ENGG100 with

DELETE FROM COURSE WHERE cnum = 'ENGG100';

Then the first transaction commits the deletion o ENGG103 and the second transaction commits the deletion of ENGG100.

Listing of the courses that have a code starting from ENGG confirms that both courses EMGG100 and ENGG103 have been deleted.

It is a corruption of a database because only one fo the courses supposed to be deleted.

REPEATABLE READ isolation level

Continued from the previous slide ...

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;
			    SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';
                              cnum   |               title                
                            ---------+------------------------------------
                             ENGG103 | Materials in Design
                             ENGG100 | Engineering Computing and Analysis
                             ENGG111 | C++

  
	                     DELETE FROM COURSE WHERE cnum = 'ENGG100';

COMMIT;

                             COMMIT;

SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';
  cnum   |               title                
---------+------------------------------------
 ENGG111 | C++

Transaction Processing in PostgreSQL DBMS

Outline

Transaction scope
Isolation levels in PostgreSQL
READ COMMITTED isolation level
REPEATABLE READ isolation level (SI)
SERIALIZABLE isolation level (SSI)

SERIALIZABLE isolation level

Write skew is not possible

We would like to remove one of the courses, either ENGG100 or ENGG103

BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';
  cnum   |               title                
---------+------------------------------------
 ENGG103 | Materials in Design
 ENGG100 | Engineering Computing and Analysis
 ENGG111 | C++

  
DELETE FROM COURSE WHERE cnum = 'ENGG103';

Continued on the next slide ...

The second transaction also lists all courses whose code starts from ENGG with the following SELECT statement.

SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';

And when the existence of ENGG100 is confirmed it deletes the course with

DELETE FROM COURSE WHERE cnum = 'ENGG100';

Immediately after the deletion the second transaction successfully commits its deletion.

Then the first transaction tries to commit its deletion of a course ENG103. This time COMMIT fails with a message

ERROR: could not serialize access due to read/write dependencies among transactions

DETAIL: Reason code: Canceled on identification as a pivot, during commit attempt.

It means that any concurrent and interleaved sequence of read/write operations on the same table performed by two transactions are impossible at SERIALIZABLE level.

SERIALIZABLE isolation level

Continued from the previous slide ...

     
                            BEGIN;
                            SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
			    SELECT cnum, title FROM COURSE WHERE cnum LIKE 'ENGG%';
                              cnum   |               title                
                            ---------+------------------------------------
                             ENGG103 | Materials in Design
                             ENGG100 | Engineering Computing and Analysis
                             ENGG111 | C++

  
	                     DELETE FROM COURSE WHERE cnum = 'ENGG100';

                             COMMIT;

COMMIT;

   
ERROR:  could not serialize access due to read/write dependencies among transactions
DETAIL:  Reason code: Canceled on identification as a pivot, during commit attempt.

References

PostgreSQL 3 Documentation, Chapter 3. Advanced Features, 3.4 Transactions
PostgreSQL 3 Documentation, SQL Commands, SET TRANSACTION
E. Rogov, PostgreSQL 14 Internals, Postgres Professional, 2023
D. R. K. Ports, K. Grittner, Serializable Snapshot Isolation in PostgreSQL, Proceedings of the VLDB Endowment, Vol. 5, No. 12, 2012