Read Committed) When a transaction runs at this isolation level, a SELECT query can only see the data submitted by the query and never see uncommitted data or other parallel transactions in other parallel in the query. Make changes. (However, SELECT does see the results of the previous update. Even if they have not submitted it, it is also seen.) In fact, a SELECT query sees a snapshot of the instantained database where the query starts running. Note that two adjacent Select may see different data, even if they are in the same transaction, because other transactions will be submitted when the first SELECT is executed.
Read has been submitted
Read committed is the default isolation level in PostgreSQL. When a transaction runs at this isolation level, a SELECT query can only see the data submitted by the query and never see uncommitted data or changes in other parallel transactions when the query is executed. (However, SELECT does look at the results of the previous update in the same transaction. Even if they have not submitted it, it is also available.) In fact, a SELECT query see a snapshot of the instantained instantained instantament starting. Note that two adjacent select commands may see different data, even if they are in the same transaction, because other transactions will be submitted when the first SELECT is executed.
Update, Delete, or Select for update is the same as the behavior and Select of the target line: They can only find the rows that have been submitted at the beginning of the command. However, such a target row may have been updated by other concurrent transactions (or delete, or tagged as updated) when found. In this case, the upcoming update will wait for the first update transaction commit or rollback (if it is still processing). If the first update rolls, its role will be ignored, and the second update will continue to update the original discovery. If the first update is submitted, if the first update is deleted, the second update will ignore the row, otherwise it will try to apply its operation on the updated version of the row. The system will recalculate the command search criteria (WHERE clause) to see if the row has been updated. It is not that still in line with the search criteria. If so, the second update continues its operation, starting from the updated version of the row.
Because the above rules, the updated commands may see inconsistent snapshots - they can see the effects that affects the concurrent update commands they try to update, but they can't see those commands in the database. Such behavior makes reading the submitted mode is not suitable for use of commands involving complex search criteria. However, it is correct for simple situations. For example, suppose we update the bank balance with a command like the following:
Begin; Update Accounts set balance = balance 100.00 Where acctnum = 12345; Update Accounts set balance = balance - 100.00 where acctnum = 7534;
If two concurrent matters tries to modify the balance of account 12345, we will clearly hope that the second transaction is updated from the updated version of the account line. Because each command only affects a row that has already been decided, so that it does not see the updated version will not lead to any inconsistent issues.
Because every new command starts from a new snapshot, this snapshot contains all transactions that have been submitted until this time, so the back of the same transaction will see any The effect of concurrent matters is submitted. The problem to consider here is whether we see if you see an absolutely consistent database in a command. Some transaction isolations provided by the submit model are sufficient for many applications, and this mode is fast, and it is easy to use. However, for the application of complex queries and updates, it may be necessary to ensure that the database has a more stringent consistency view provided by reading the submitted mode.
12.2.2. Serialized isolation level
The serializable level provides the most stringent transaction isolation. This level simulates serial transaction execution, as if the transaction will be serialized in a followed by one, not the parallel execution. However, using this level of applications must be prepared to re-launch the transaction when serialization failed.
When a transaction is in a serialized level, a SELECT query can only see the data submitted by other parallel transactions in transaction execution that can never be submitted before the data is submitted before the transaction begins. (However, SELECT does see the effect of the update in the same transaction. Even if the transaction is not submitted, it is not the same.) This behavior is not the same, its SELECT is seeing the start of the transaction. Snapshots, not a snapshot at the beginning of the current query inside the transaction. In this way, the SELECT command behind a transaction always sees the same data.
Update, Delete, and Select For Update are the same as behavior on the search target line: they will only look for the target rows that have been submitted at the beginning of the transaction. However, such a target row may have been updated by another concurrent transaction (or deleted or tagged as an update) when discovered. In this case, the serving transaction will wait for the first transaction submit or rollback (if it is still processed). If the first update is rolling, its impact will be ignored, and this can continue to update the row it originally discovered. But if the first update is submitted (and the row is actually updated or deleted, not just to select it), the serialized transaction will roll back and return to the following information.
Error: Can't Serialize Access Due to Concurrent Update
Because a serialized transaction cannot change the rows that have been changed by other transactions after the stroke transaction.
When applying such an error message, it should exit the current transaction and then re-transaction from the beginning. The second runtime, the previous submission of the transaction is part of the initial look of the database, so the starting point for the new version of the line does not have a logical conflict.
Please note that only update transactions need to retry, read-only transactions have never serialized.
The serialized transaction level provides a strict guarantee: each transaction sees a view of a fully consistent database. However, if the parallel update makes the database can't maintain the serial execution, then the application must prepare the transaction. Because the overhead of the redo complex transaction may be very considerable, we only recommend that the update command contains sufficient complex logic, which can be used in the case where the submitted level may result in errors. The most common thing is that the serialization mode is only necessary in this case: a transaction continuously makes several commands, and these characters must see the exactly the same view of the database.
