PostgreSQL transaction model Introduction

PostgreSQL has its own transaction implementation model. Generally, there are three layers: toplayer, middlelayer, and bottomlayer.

PostgreSQL has its own transaction implementation model. There are three layers: top layer, middle layer, and bottom layer.

PostgreSQL has its own transaction implementation model. There are three layers: top layer, middle layer, and bottom layer.

1. Top Layer

The Top Layer is mainly controlled by users and visible to users. This layer of transactions is mainly determined by the user to initiate and end the transaction. The transaction lifecycle is controlled by the user and is high-level.

That is, the transaction block, transaction block. When a user initiates commands such as BEGIN, COMMIT, ROLLBACK, SAVEPOINT, rollback to or RELEASE,

The traffic cop of PG forwards these calls to the Top Layer routine again. The corresponding method is as follows:
BeginTransactionBlock
EndTransactionBlock
UserAbortTransactionBlock
DefineSavepoint
RollbackToSavepoint
ReleaseSavepoint

2. Middle Layer

This layer is basically at the statement level. Invisible to users, that is, users cannot control the specific lifecycle. The processing of this layer corresponds to the statement. The corresponding method is as follows:

StartTransactionCommand
CommitTransactionCommand
AbortCurrentTransaction

3. Bottom Layer

This is the atomic Implementation of the transaction at the lowest level, which is at the row-level. Is the true transaction implementation and nested transaction processing.

The method is as follows:

StartTransaction
CommitTransaction
AbortTransaction
CleanupTransaction
StartSubTransaction
CommitSubTransaction
AbortSubTransaction
CleanupSubTransaction

From the above three-layer model, we can see that PG transaction management granularity is from coarse to fine. The call is called from the middle layer to the bottom layer. In addition, if there is user-level transaction control, such as "BEGIN", it will be forwarded to the top layer by ipvs. c.

Assume the following case:

1) BEGIN
2) SELECT * FROM foo
3) insert into foo VALUES (...)
4) COMMIT

The calling method is sequential as follows:

/StartTransactionCommand;
/StartTransaction;
1) <ProcessUtility; <BEGIN
\ BeginTransactionBlock;
\ CommitTransactionCommand;

/StartTransactionCommand;
2)/ProcessQuery; <SELECT...
\ CommitTransactionCommand;
\ CommandCounterIncrement;

/StartTransactionCommand;
3)/ProcessQuery; <INSERT...
\ CommitTransactionCommand;
\ CommandCounterIncrement;

/StartTransactionCommand;
/ProcessUtility; <COMMIT
4) <EndTransactionBlock;
\ CommitTransactionCommand;
\ CommitTransaction;

In step 1, the start of the transaction boundary defined by the user is also the starting point of the transaction lifecycle.

First, "BEGIN" is also used as a command statement, so this step also requires the method call in the middle layer to enclose it.

Start the low-level transaction, that is, the middle layer calls the bottom layer method. When StartTransaction is performed, vxid (virtual transaction id, that is, backend id and local transaction id) is generated ).

Checks whether the current transaction is read-only or is in the recovery status. The transaction isolation level, whether the transaction is asynchronous commit, and other information are initialized here. Set the transState status to TRANS_INPROCESS.

Because there is a "BEGIN" command statement, it is top layer. Therefore, it is transferred to the BeginTransactionBlock logic. Start transaction block Processing and set the transaction status to TBLOCK_START.

The difference between a transaction block and a transaction is that the transaction status is set differently.

The start trasaction block sets the transaction status to TBLOCK_START, while the general start transaction is set to TRANS_INPROCESS.

Transaction blocks differ from transactions in terms of status. Transaction blocks can be nested in the following states:

General transactions have only the following statuses and are not nested:

In addition, different struct structures are used to save the source code definition. TransState to save the low-level Transaction status.
TBlockState stores the high-level Transaction status. It can be seen from this that PG has made a distinction at the transaction level.

In step 2, initiate the select query. As mentioned above, the middle layer corresponds to the command statement. Therefore, the select query is surrounded by method calls in the middle layer.
In addition, the CID is added for MVCC visibility judgment in the same transaction.

In step 3, initiate the insert operation. This step is basically equivalent to step 2 in logic. Only when processing insert, you need to update the current xid to the tupler header.
Operations such as insert, update, and delete are usually closely related to heap, and involve physical addition and deletion of tuple on heap. In this layer, PG needs
Operation assign a transaction ID, and update this transaction ID to xmin or xmax in the tuple header. To achieve MVCC. In addition, commandID is added for this layer to realize visibility judgment in the same transaction.

In step 4, the user initiates a commit to submit the transaction. The transaction lifecycle ends. This step is logically equivalent to the first step. The transaction block of the top layer must be ended. You also need to end the transactions in low-level to implement
Transaction atomicity. You also need to release resources, buffer pin, and lock.

From the above explanation, we can clearly see the general logic of PG in transaction implementation. Complete ACID implementation.
Atomity: Atomicity is implemented at the low-level, starting from StartTransaction and ending with CommitTransaction.
Consistency: The Consistency is implemented at the statement level, that is, the middle layer. In addition, the updated xmin, xmax, cmin, and cmax in the tuple header provide the judgment basis for transaction visibility.
Isolation: Initialize the transaction Isolation level during StartTransaction. Provides the foundation for creating snapshot for MVCC.
Duarability: implemented through CommitTransaction, commit transaction logs, and so on. Provides the foundation for data recovery and persistence. Implement the WAL (Write Ahead Log) function.

------------------------------------ Lili split line ------------------------------------

Install PostgreSQL 6.3 on yum in CentOS 9.3

PostgreSQL cache details

Compiling PostgreSQL on Windows

Configuration and installation of LAPP (Linux + Apache + PostgreSQL + PHP) Environment in Ubuntu

Install and configure phppgAdmin on Ubuntu

Install PostgreSQL9.3 on CentOS

Configure a Streaming Replication cluster in PostgreSQL

How to install PostgreSQL 7/6 and phpPgAdmin in CentOS 5/6. 4

------------------------------------ Lili split line ------------------------------------

PostgreSQL details: click here
PostgreSQL: click here

This article permanently updates the link address: