Review for Paper: 14-Serializable Snapshot Isolation in PostgreSQL

Review 1

Formerly, PostgreSQL offered no isolation level higher than snapshot isolation (SI), which does not guarantee serializability. Although snapshot isolation guarantees that any transaction's reads will be repeatable, and each transaction must acquire a tuple-level lock before making any writes, there are cases where concurrent transactions can produce non-serializable results. Therefore, it was decided to implement serializable snapshot isolation (SSI) in PostgreSQL, a serializable level that can be built on top of the pre-existing snapshot mechanisms without the overhead of strict two-phase locking.

In “Serializable Snapshot Isolation in PostgreSQL,” the authors present the first implementation of SSI in a production database. In an SSI system, transactions operate on independent database snapshots and use tuple-level write locks, as in normal snapshot isolation. To ensure serializability, a graph of read-write anti-dependencies is maintained and checked for cycles, which indicate a non-serializable set of concurrent transactions is in progress. When such a “dangerous structure” is detected, one of the transactions is aborted, though it could be restarted later by the calling application. This is a form of optimistic concurrency control that ensures serializability, but may produce greater throughput than S2PL for some workloads by avoiding blocking and lock management.

The authors' main contributions are a serializable isolation level integrated with PostgreSQL for the first time; the first production-level SSI implementation; a discussion of challenges faced when applying SSI to a production DBMS that had not previously had serializability from S2PL; and performance tests. Tests on the DBT-2 and SIBENCH benchmarks show that SSI performs significantly faster than (a naive implementation of) strict two-phase locking in PostgreSQL, and that SSI is only slightly slower than SI, the non-serializable version of snapshot isolation. One of the key insights of this work is that to ensure serializability, it is sufficient to track rw-antidependencies, ignoring write-write and write-read dependencies, because every “dangerous structure” has a chain of two rw-antidependencies. This leads to a simpler, faster, and less memory-intensive SSI implementation.

One drawback to the implementation of SSI in the paper is that, as the authors admit, some false positives may be made in the detector for potentially conflicting transactions, leading to transactions being aborted unnecessarily. An alternative design of SSI would track all dependencies that are needed to produce a cycle constituting a conflict, and use a graph cycle detector to test for conflicts. This could be useful under some workloads, where false positives are common.

Review 2

The paper deals with the implementation of a new serializable level in PostgreSQL based on a technique called Serializable Snapshot Isolation Technique. This isolation level was deemed necessary since the concurrently-executing transactions produce numerous conflicts and aborts leading to delay in execution time and the method to overcome this (two-phase locking mechanism) was seen as too expensive by the database analysts.

The authors explain that snapshot isolation if unserializable can cause such cases in which the invalid data is not discovered until much later when the error cannot be easily reproduced making the cause difficult to track down. Concurrency issues are difficult to deal with. The anomalies of snapshot isolation are related to dependencies such as write-read dependency, write-write dependency and read-write antidependency. SSI are related to rw-dependency in which a transaction writing an object has to do it after another transaction reading the same object so as to avoid inconsistency in the data. Safe snapshots are used to mitigate serializable failure.

The authors throw light on the implementation of SSI in PostgreSQL and problems related with them are addressed. One of the main requirements of SSI is to be able to detect rw-conflicts as they happen. This is done by the implementation of a new Lock Manager by the authors which tracks snapshot isolation locks and checks for conflicts. The conflicts which happen are resolved using safe retry which says that when we retry an aborted transaction immediately, it will not cause it to fail again with the same serialization failure. The memory usage is mitigated by limiting the lock manager.

The authors are successful in developing the SSI technique and have implemented it into PostgreSQL. The paper succeeds in highlighting its implementation and also the creation of a lock manager to aid SSI in achieving great performance. The tests at the end quantify its results efficiently.

The tests in the end show that SSI is not better than normal SI during various transactions leading to the fact that serializability does provide good read rates over 2PL but still has performance costs which users are unwilling to ignore. The technique may help in the future as it deals with concurrency issues but wont be adopted soon by DBAs owing to its performance compromise.

Review 3

What is the problem addressed?
This paper describes the experience of implementing a new serialisable isolation level on PostgreSQL. It presents how they overcame some of the implement challenges such as implementation of new lock manager, ensuring memory usage is bounded.
Why important?
Though serializable isolation for transactions is an important property which allows application developers to write transactions as though they will execute sequentially, without regard for interactions with concurrently-executing transactions, not all popular open source database, like PostgreSQL, provides a serializable isolation level because the standard two-phase locking mechanism was seen as too expensive.

On the other hand, snapshot isolation offers greater performance but allows certain anomalies. Recently they introduced a serializable isolation level that retains many of the performance benefits of snapshot isolation while still guaranteeing true serializability.

It uses an extension of the Serializable Snapshot Isolation (SSI) which runs transactions using snapshot isolation, but checks at runtime for conflicts between concurrent transactions, and aborts transactions when anomalies are possible.
1-­‐2 main technical contributions? Describe.
They extended SSI to improve performance for read-only transactions, an important part of many workloads. They improve performance for read-only transactions in two ways. First, the theory enables a read-only snapshot ordering optimization to reduce the false-positive abort rate, an improved version of the commit ordering optimization. Second, they also identify certain safe snapshots on which read-only transactions can execute safely without any SSI overhead or abort risk, and introduce deferrable transactions, which delay their execution to ensure they run on safe snapshots.

Lacking this locking mechanisms, we were required to build a new lock manager. The lock manager is specifically optimized for track- ing SSI read dependencies, making it simpler in some respects than a classic lock manager but also introducing some unusual challenges. They use this lock manager, along with multiversion concurrency control data, to detect conflicts between concurrent transactions. They also introduce a safe retry rule, which resolves conflicts by aborting transactions in such a way that an immediately retried transaction does not fail in the same way.

1-­‐2 weaknesses or open questions? Describe and discuss
The comparison is not quite accurate, since few database implement serialisable isolation with strict two phase lock, and there are a lot of alternatives can apply such as optimistic concurrency control, timestamp-base concurrency control. An important open question is that what kind of isolation really matter.

Review 4

This paper presents a new serializable isolation level in PostgreSQL, which is based on Serializable Snapshot Isolation (SSI) technique. The contribution is outstanding in PostgreSQL community, since the new design is the first to put in production use and the first in a database which did not provide a serializable isolation level (PostgreSQL did not provide serializability for simplifying developments by allowing users to ignore concurrency issues). The new design includes the implementation of a new lock manager, a transaction summarization technique to ensure memory usage is bounded, as well as the integration with other PostgreSQL features.
This paper first provides an overview about snapshot isolation and SSI technique. Then it moves to an extension of SSI for read-only transactions. Following that is the new design in PostgreSQL 9.1, as well as the technique to bound memory usage and integration with other existent features. Also, it provides a detailed performance evaluation using several benchmarks.

The general problem here is that PostgreSQL did not provide a serializable isolation level previously (one reason is that S2PL is too expensive to implement comparing other performance cost). Here is a tradeoff between whether or not to implement a serializable isolation level. On the one hand, serializable isolation is a very important property for transactions because it allows application developers not to consider the interactions between concurrent transactions. On the other hand, creating one might be expensive and without serializable isolation there might be an improved performance under some cost (for example, PostgreSQL’s highest isolation level was snapshot isolation).

The major contribution of the paper is that they successfully implements SSI in PostgreSQL in production use. From the evaluation, the new design performs only slightly below that of snapshot isolation (previous highest isolation level), and significantly outperforms the traditional S2PL on read-intensive workloads. Another important contribution is that the new isolation level integrates with other PostgreSQL features including two-phase commit, streaming replication and savepoints and subtransactions.

One interesting observation: This paper is very innovative and the new serializable isolation level embedded in new PostgreSQL version is very attractive according to the performance measurements provided in the paper. However, I noticed that all implementations are based on a serializability theory which identifies the “dangerous” structure. There is not much proof about this theory, so I just wonder a little bit about what will happen if this theory is not 100% correct.

Review 5

This paper describes the experience and challenges of implementing Serializable Snapshot Isolation (SSI) technique into PostgreSQL. Although SSI was proposed and implemented before, this paper still has much value due to the novel optimization techniques they proposed and implemented and the fact that it was the first implementation of SSI in a production database which demonstrates the difficulty and challenges especial to production environments.

The first four pages of the paper mostly provide the the background information about snapshot isolation and SSI. The authors have done a good job in providing good examples to show why snapshot isolation does not bring about serializability and can be dangerous in some situations. The rest of the paper is about the optimizations and implementation details. The most important optimization technique, in my opinion, is the concept of "safe snapshot" which not only reduces the overhead of concurrency control of read-only transactions, but also allows DBMS to support "defferable transactions" which can be very useful for long-running, non-urgent tasks, like backups. Also I liked their techniques used for limiting the memory usage by SSI functionality. These techniques guarantee that, no matter what, the memory used by SSI functionality would not become more than a certain amount. the last section of paper is a report of performance evaluations. The reports show that the performance of their implementation of SSI is very similar to SI in most cases. So, we get true serializability without much cost of performance.

Despite their nice work and ideas, I think there are some flaws in the performance evaluations. Firtly, the S2PL they have used in evaluations is really basic and not optimized, while they have used many optimizations on their SSI implementation. Thus, we can just say their implementation of SSI performs much better than the basic implementation of S2PL, not S2PL in general. I'm pretty sure that SSI will outperform an optimized implementation of S2PL because it has less false positive abortions, but the difference might be much less than what we see here. Secondly, they have discussed about the techniques they used for reducing memory usage, but nowhere they mentioned how much memory was consumed by SSI functionality in the experiments and how higher/lower it is in comparison with the memory S2PL uses.

Review 6

This paper discusses how PostgreSQL was able to provide serializable snapshot isolation, without the use and two phase locking like most other database management systems. Instead of paying for the over heading of the locking, Postgres had previously only offered snapshot isolation, which allows certain anomalies. Because Postgres did not have a two-phase locking system already, they could not used that to build the SSI system, and instead had to build their own lock manager from the ground up. A system like MySQL, on the other hand, would have been easier to support because it already supports 2PL. They use their new lock manager, along with their MVCC, to detect conflicts between transactions and retry them when its safe.

The motivation behind this work is simple - users should be able to issue transactions to the database without any concern about how they are interleaved with other running transactions. However, PostgreSQL did not provide this level of isolation. The paper discusses the theory behind SSI, and the possible conflicts. Essentially, the system tracks rw-anti-dependencies (rw-conflicts) to see if their is an issue. If their is, it waits until it had determined that is is safe to retry, to as to avoid repeatedly trying and aborting an transaction.

The authors did a great job of explaining how they were implementing this complex idea, while keeping the focus on the user the whole time. They did not implement serializability until they had a system that could do so efficiently - they didn't think the overhead of 2PL was worth it, so they waiting until they had a method to add the feature, rather than use a slow hack. They showed the background, the theory, and gave us plenty of information on Postgres.

This paper could have done a better job in the experimental results section. It didn't include that much data - I would have liked to have seen the performance of all of the different serializable levels, and how they compared. I also find transactions to be a weak measurement - are they long running, complex, analytic transactions, or short-read only?

Review 7

The paper put forward in the paper is that a new serialization method is needed in PostgreSQL. It is because two-phase locking is too expensive, while the snapshot isolation which has better performance has come anomalies. Even though techniques are developed to solve the anomaly problems, it is too hard and beyond the ability of many users to handle the issue because it involves the concurrency problems. So the PostgreSQL should be able to handle the anomalies with a new method which has a better performance than 2PL.

The solution proposed is to implement the Serialization Snapshot Isolation(SSI) technique in PostgreSQL, which is the first implementation of SSI in a production database release and for a snapshot-based DBMS. The approach, which is SSI, is based on snapshot isolation, while improving it by detecting the anomalies and resolving them. The anomaly happens only when two adjacent rw-antidependency transactions both have an incoming and an outgoing rw-antidependency. So the wr- and ww-dependencies are ignored in SSI. The database implements a lock manager to detect conflicts since there is no necessary information in PostgreSQL’s existing lock manager. The conflicts should be tracked because the criteria for an anomaly is two adjacent rw-antidependency transactions. The paper makes it by keeping a list of all illegal in or out for every transaction. When a conflict is detected, the corresponding transactions will be aborted. After that, the conflict is resolved by safe retry without the same serialization failure. Also, SSI improves the performance of the read-only transactions since it is frequently used.

The strength of the paper is that it provides quite a lot introductions and background for the definitions snapshot isolation, the analysis of SI anomalies and the serializability theory. It provides multiple figures and examples to explain the problem, which is quite accessible to a reader with no experience in it.

Meanwhile, the drawback is that this paper talks about very little about the shortcomings and the possible future work of the SSI method. It may stop other developers to make valuable improvements. Also, it increases the difficulties for other database designers to find out the tradeoff between SSI and S2PL.

Review 8

This paper goes over the concept of serializability and snapshot isolation, the serializable snapshot isolation technique (SSI), and the various challenges and techniques that were required to implement SSI on a PostgreSQL database. Snapshot isolation (SI) is when all reads within a transaction see a consistent view of the database, as if the transaction operates on a private snapshot. With serializable snapshot isolation, it ensures serializability of transactions by running transactions using snapshot isolation, but adding additional checks to determine whether anomalies are possible. With SSI, we can avoid blocking and take advantage of the high performance of snapshot isolation. When transactions do end up violating serializability, they are simply aborted and rolled back using existing functionalities of snapshot isolation. When SSI was integrated into PostgreSQL, the system needed to implement a new predicate lock manager for tracking read dependencies of the transactions. Furthermore, a transaction summarization technique was necessary in order to bound the memory usage. The paper discovered that implementing SSI is more challenging than a typical S2PL-based serialization.

The paper does a good job addressing the various implementation details of bringing SSI to PostgreSQL, and describing why certain changes were necessary. Based on the performance results reported, it appears SSI did indeed provide significant performance improvement over S2PL, despite the implementation challenges. One area of concern is that it required couple optimization and additional modules for SSI to function properly on PostgreSQL. Isn’t it possible that if similar effort was put into optimizing S2PL, we would have got comparable performance?

Review 9

This paper introduces a new isolation level in PostgreSQL: Serializable Snapshot Isolation(SSI). It is not only similar to snapshot isolation with little overhead in locking but also guarantees serializability using conflict detection and multi version concurrency control.

This paper actually implements the SSI in new release of PostgreSQL, which not only solves the serializable problem, but also preserves the non-blocking feature(SI) in PostgreSQL. The serializability can give the user the abstraction that all the transactions are isolated and relief much burden on the users to ensure the data consistency. SSI makes it easier for user to reason the database behavior. In addition, the SSI implementation in the PostgreSQL has less overhead than strict 2PL. A new lock manager is created to track down SIREAD lock only, which is non-blocking. Several optimization is also implemented, such as safe snapshots and deferrable transactions. As shown this paper, the SSI outperforms 2PL in several benchmarks tested, especially with much read-only workload.

As mentioned, it is the first time of a new isolation level first added to a existing database. Adding an isolation level is non-trivial task and their experience is worth learning. It may become a good reference to future works like serializable snapshot isolation in a parallel systems.

A main drawback of this paper is about the memory usage. Theoretically, the SSI implementation can consume unlimited memory. Though the paper introduces several memory usage optimization methods, there is still chance that the memory is used up due to a large amount of concurrent transaction and limited memory. Under this situation, the performance may degrade dramatically.

Review 10


PostgreSQL uses snapshot isolation for its concurrency control. Snapshot isolation does not allow the three kinds of concurrency errors in the ANSI SQL standard: dirty read, non-repeatable read, and phantom read. However, other kinds of errors may occur in snapshot isolation- e.g. if two transactions read A and B respectively and then write B and A respectively, then it is possible for a non-serializable result.

The paper aims to solve this problem using Serializable Snapshot Isolation. First they define the rw-dependency, which happens when one transaction writes an object, but another transaction’s snapshot does not see the update. They then determine that errors can occur if in the dependency graph A -> B and B -> C are rw-dependencies, and ABC are part of a cycle where C commits first.

In order to keep track of these dependencies, the authors kept track of all rw-antidependencies into and out of a transaction. If they detect that the situation above occurred, such that A->B->C and C commits, then they try to abort B or A to break up the dependency cycle. Additionally, optimizations can be made for read-only queries, because often it can be determined at snapshot time that they will not cause conflicts, and so they can run without dependency checking. This allows SSI to perform well on workloads that have many read-only queries. The performance results of the paper show that SSI performs almost as well as SI, and better than S2PL in workloads that have many read-only queries.


The paper shows a clear problem with SI, and explain the theory of the problem in an understandable way. They show that their solution solves the problem at small cost to performance.

Weaknesses/open questions:

The description of rw-antidependency in the definition seemed to mix up T1 and T2, and the use of “before” and “after” seemed to be contradictory to a subsequent paragraph, which was highly confusing for a while.

Their tests show that SSI seems to perform as well or better than S2PL for workloads with any ratio of read-only to non-read-only queries. Why then are people still using S2PL?

Review 11

The paper discusses the implementation of Serializable Snapshot Isolation in PostgreSQL. Even though “SERIALIZABLE” is the strongest isolation level possible, it is not often used or not even provided by mant DBMS as enforcing it may cause a significant performance loss. For example, Oracle DBMS only provides snapshot isolation even when a user specifies “SERIALIZABLE” as its isolation level. The contribution of this paper is an implementation of Serializable Snapshot Isolation (SSI) to achieve serializability in a popular DBMS with a relatively small performance loss compared to snapshot isolation.

The main work of the paper is a realization of Serializable Snapshot Isolation technique developed in another paper. It was natural for the authors to apply these techniques to PostgreSQL as PostgreSQL is purely snapshot-based. However, it turns out in the paper that the implementation requires snapshot isolation plus a separate lock manager, which could be more complex in some area than a lock manager infrastructure required to support Strict Two Phased Locking (S2PL).

The implementation of SSI in the paper is based on the theorem proved in the work of Fekete et al. that every cycle in a serialization history graph contains at least two rw-antidenpencies. Rw-antidependencies are the case where a transaction writes to an object and another transaction reads the previous version of the object. By detecting such case, it can find every serialization anomaly and prevent them by aborting one of the transactions forming the cycle afterwards. However, to do so, the authors have to implement a dedicated SSI lock manager along with other isolation features in PostgreSQL, which needs to consider many different anomaly situations that may happen.

Nonetheless, the complexity of the implementation pays off as SSI achieves only 5-10% less throughput compared to that of SI and outperforms S2PL by a significant margin. One downside of their experiment is that the paper only focuses on comparing the performance of different isolation levels. The authors do not evaluate the correctness of their approach and implementation without checking whether data is corrupted after running each workload. This is because the implementation of the paper is almost useless unless the serializability achieved by their approach is perfect. I think that a single experiment to validate data correctness would have been a good supplement to the paper.

In conclusion, the paper implements SSI techniques proposed in another paper in a real-world DBMS, PostgreSQL, and achieves serializability with small overheads. The main strength of the paper comes from its extension to the previous theoretical work on the topic and the realization to prove that it actually works in the real-world. As a final remark, I am just curious which isolation level is frequently used with PostgreSQL in practice nowadays. The insignificant performance loss of SSI reported in the paper seems enough to make “SERIALZABLE” as the default isolation level, but the most recent version (9.4) of PostgreSQL still offers “READ COMMITTED” as the default.

Review 12

Before this paper. PostgreSQL did not provide a serializable isolation level due to the expense of two-phase locking protocols. Instead, PostgreSQL used snapshot isolation since it had better performance. However, snapshot isolation does not guarantee serializable isolation. The paper discusses a new technique Serializable Snapshot Isolation (SSI) and the experiences of the authors when implementing it in PostgreSQL.

The paper first demonstrates the importance of maintaining serializable isolation between transactions and then gives a brief description of SSI. SSI is similar to optimistic concurrency control (OCC) in that is allows transactions to run concurrently without a locking mechanism, but uses checks to detect if possible conflicts occur. However, SSI allows what it defines as a rw antidependency conflict to occur so long as it is not part of a dangerous structure. OCC and two-phase locking prevent such actions occurring, but according to serialization theory, one rw antidependency isn't dangerous. It is when a node has a antidependency going in and out, called a dangerous structure in the paper, that it presents a problem, due to a possible cycle.

One of the main difficulties in implementing SSI in PostgreSQL was what pre-existing mechanism should be used. Previous SSI implements were built on read locks, but PostgreSQL does not require read lock for data. The authors created a new lock manager that works with multiversion concurrency control data already within PostgreSQL to enforce SSI. Another difficulty was implementing SSI in a memory constrained environment. The paper notes that long running transactions can make the memory cost of naive SSI large. To combat this problem, the paper lists four additional techniques used.

The performance of PostgreSQL with SSI is comparable to snapshot isolation according to the graphs presented. The paper discussed one major simplification of SSI which was only tracking rw antidependencies. This simplification reduced the memory footprint of SSI, but it is clear that even this results in some overhead over normal snapshot isolation. Although not a weakness of the paper, I think the authors should have considered adding support for tracking of the two other dependencies, which would result in a stronger version of SSI. Users could choose whether they wanted SSI or PSSI as a setting, similar to how users currently choose an isolation level. Although the memory and CPU cost would increase, it may be acceptable for users with more powerful hardware. Furthermore, by adding the mechanisms into PostgreSQl, it would make it easier for developers to possibly improve the performance of PSSI since the difficulty of integrating the system into PostgreSQL would have already been done by the authors.

Review 13

Different DBMSs might provide different levels of isolation for transaction processing with serializability being the strongest isolation level. This paper introduces a Serializable Snapshot Isolation (SSI) technique, and then extends it and applied it to PostgresSQL database, which only provided Snapshot Isolation but no Serializable isolation because of the high cost of locking schemes.

Many DBMSs, including PostgresSQL, previously provide a "serializable" mode which is really not serializable. For PostgresSQL, it only provide Snapshot Isolation:

1. Better efficiency than Serializable Isolation using S2PL.
2. All reads in a transaction see a consistent snapshot view of the database.
3. No ANSI SQL standard anomalies would happen but there might be some other anomalies.
4. Some other techniques are developed to fix those anomalies.

SSI is built on top of Snapshot Isolation but casts additional checks on it. If a transaction is detected to have potential anomalies that violate serializability, it will be aborted. SSI has several advantages over Serializable Isolation using S2PL of OCC:

1. Less expensive runtime checking:
SSI looks for dangerous structures composed of rw-antidependencies. Thus it does not need to check other edges which is need for the cycle testing in the serialization graph.

2. Greater concurrency:
SSI allows rw-conflicts as long as they do not form a dangerous structure while rw-conflicts are not allowed at all for S2PL and OCC.

This paper also discusses about some implementation details on PostgresSQL, including conflicts detection and resolving, as well as their optimizations for read-only transactions. In addition, several issues that arise when integrating SSI into PostgresSQL, such as memory usage and some existing features, are also covered.

The main contribution of this paper is not only that it is the first work that actually implements SSI in a production database release but also that they sheds light on the interaction between the new technique and the traditional features in PostgresSQL.

Review 14

This paper discusses integrating SSI (Serializable Snapshot Isolation) in PostgreSQL. The motivation for this is because serializable isolation is an important property for transactions, allowing application developers to write as if the transactions execute sequentially, freeing them from having to consider interactions with concurrently executing transactions. SSI uses snapshot isolation when running transactions, but, at runtime, will check for conflicts between concurrent transactions and will abort transactions that are suspect to anomalies.

Snapshot isolation allows all reads within a transaction to see a consistent view of the database. However, snapshot isolation displays unexpected behavior in the face of dirty reads, non-repeatable reads, and phantom reads. There are techniques to avoid the anomalies (workloads without the anomalies are serializable under snapshot isolation, explicit locking with PostgreSQL's LOCK LABLE and SELECT FOR UPDATE, materialize conflicts with a dummy row that represents the conflict, using foreign key, uniqueness, or exclusion constraint to enforce an integrity constraint), but they are difficult to deal with. Serializable snapshot isolation, on the other hand, runs transaction with snapshot isolation, but uses additional checks to determine when anomalies are possible. SSI also does not require additional blocking. SSI checks for two adjacent rw-antidependency (also known has rw-conflicts, a transaction writes to an object, another transaction reads the object before the first transaction commits) edges ; where a transaction has an incoming rw-antidependency and an outgoing rw-antidependency, SSI aborts one of them, ensuring serializable execution. Although there may be false positives, this is efficient because it is less expensive in runtime than cycle testing and there is no need to track wr- and ww-dependency edges. rw-antidependicy edges are detected using the SIREAD lock, which do not block conflicting writes, flag an rw-antidependency on a SIREAD lock and write conflict, and persist after a transaction commits. The rate of false-positive aborts is decreased with the read-only snapshot ordering optimization, which takes into account whether or not a dangerous structure is read-only; if it is, it can be determined to be a false positive, unless the last transaction commits before the first snapshot. When a read-only transaction has no concurrent read/write transactions committed with rw-antidependency out of the committed read-only transaction's snapshot, the read-only transaction is known as a safe-snapshot. A new SSI feature, deferrable transactions, then allow complex read-only transactions to only run on safe snapshots.

In PostgreSQL, the Lock Manager uses S2PL-based serializability and handles predicate reads using index range locks. Locks on the B+ tree are acquired with page granularity. The lock manager was simplified because intention locks were not necessary when lock checks are done in order from coarsest to finest and deadlock detection is not needed because SIREAD locks cannot cause blocking. Conflicts are tracked with a list of all rw-antidependcies in and out of each transaction. Conflicts are resolved with a safe retry, for which retrying a transaction that was aborted does not cause it to fail again with the same serialization failure. Memory usage is lessened by using safe snapshots and deferrable transactions to lessen the impact of long-running, read-only transactions, granularity promotion to reduce space, aggressive clean-up to remove unneeded information of a committed transaction's state (by committing the sequence number of the earliest committed transaction that has a conflict), and summarization of committed transactions to consolidate the state of multiple committed transactions into a compact representation (but increases possibility of a false positive).

I thought the paper did a good job of discussing SSI, what it is and how it integrates in to PostgreSQL. I felt that limitations of this paper are that it could've given more discussion on what specifically SSI has allowed database management systems to do that it could not do before, and how widely SSI is used today. I would've also liked to see a discussion on databases for which SSI would not perform well.

Review 15

Serializable snapshot isolation (SSI) is the topic of this paper. It discusses the implementation in PostgreSQL, which is the first production database to have this isolation level in 2012. Previously, two-phase locking was seen as too expensive to implement serializability. The authors show how you can implement SSI to get serializability with your snapshot isolation level. They go on to discuss an optimization for read-only transactions and evaluate their algorithms on SIBENCH, DBT-2, and RUBiS benchmarks.

This paper has a lot of strengths. It implements SSI and thoroughly and clearly explains why and how this is done. The paper has a strong motivation for SSI. It talks about two examples of where snapshot isolation causes anomalies. This is interesting because in a lot of papers we see only one toy example and it is much more motivating to see the two examples in this paper. In addition, we see reasons why people did not use serializability before and how they got around the issue. The authors state that application developers should not have to worry about concurrency issues. They state that these issues are “notoriously difficult to deal with”. This is a pretty good motivation for finding a compromise between the performance tradeoff with serializability and the benefit of abstracting development from the concerns of concurrency. The authors use three benchmarks! This is excellent and shows how the techniques of SI, SSI, and S2PL vary by table size on realistic workloads.

The drawbacks of this paper are minor. The paper shows normalized results for the comparison of SI, SSI, and S2PL. This gives us an idea of how these methods compare to SI but doesn’t give us much of an idea of how long these transactions actually take. It seems clear that SSI is preferred in the read only disk-bound configuration. In the other two graphs we see that the tradeoff still exists, although it is minimized, between SSI and SI for the in-memory configuration for read-only transactions, as well as for the SIBENCH transaction throughput. It would have been more insightful to examine when it would be best to use SSI and when developers would be better off still using their old methods to avoid SI anomalies. This analysis would also provide deeper insight into what needs to be done, or what could be problems in the future.

Review 16

Part 1: Overview

This paper describes a crucial new feature, Serializable Snapshot Isolation (SSI), in the PostgreSQL 9.1 release. Previously unlike MySql, there was no serializable level isolation in PostgreSQL. This is the first implementation of serializable snapshot isolation in production database. Replication system, two-phase commit, and subtransactions of PostgreSQL are all integrated. Unlike previous work which takes advantage of the two-phase locking mechanism, in this paper they developed their own lock manager. To improve performance for the read heavy databases, they optimized the read-only transactions by reducing the false positive serialization failures. Deferrable transactions are introduced to reduce the overhead of serializable snapshot isolation.

As defined by ANSI SQL standard, a database can provide several levels of isolation. Serializability is the highest level of isolation and is really good in practice as this is most user friendly. All transactions can believe their output would be maintained even if they are running concurrently. Racing conditions are allowed at weaker levels and would lead to better performance however much more overhead. In this paper they tried to achieve high performance as well as the true serializability at the same time. Serializable snapshot isolation is what they proposed to ensure serializability and performance.

Part 2: Contributions

This paper implements the new level of isolation, which is pretty hard due to so many corner cases and tedious stuffs. They implemented a lock manager to help detect conflicts, tracking conflicts, concurrent transactions. They achieved seven percent less cost than the traditional snapshot isolation, also got better results than traditional two-phase locking.

Based on the anomaly theory, they proposed an optimization of SSI for read only transactions. They developed a read only snapshot ordering rule. Based on the ordering rule, they designed two key mechanisms to help reduce false positive serialization failures, safe snapshots and deferrable transactions respectively.

Part 3: Possible Drawbacks

The serializability provided by their work would still allow anomalies. Sometimes we may lost updates as we are experiencing fast modification and good overall performance. Though they achieved better performance than PSSI, their implementation at the same time suffers some false positive failures.

Review 17

The paper explains implementational issues of a technique called “serializable snapshot isolation” (SPI) on PostgreSQL. The snapshot isolation, originally implemented in PostgreSQL, while offering greater performance for concurrent transactions, allows certain anomalies to occur. In order to avoid these anomalies, it is important to guarantee serializability. By providing serializability, dealing with issues related with concurrent execution of transactions become much easier for application developers. Serializability could be implemented using a two-phase locking mechanism but leads to a high performance overhead. SPI is a technique which retains many of the performance benefits of snapshot isolation while still guaranteeing true serializability as two-phase locking mechanism. This technique run transactions using snapshot isolation, but adds additional checks to determine whether anomalies are possible. In order to achieve this, it created a serialization graph which capture read-write (rw) anti dependencies and checks for anomaly. For example, two concurrent transactions having a rw-antidependency with each other implies anomaly. Transactions that creates anomaly are simply aborted.

The paper proposes various optimizations to improve performance while maintaining serializability. One of the optimization is applicable for read-only transaction which creates a false anomaly. If a read-only transaction, T1, involved in a snapshot anomaly with another transaction, T2, and if T2 doesn’t commit before T1 taking its snapshot, then the anomaly can be neglected. This optimization is important because many workloads contain a significant fraction of read-only queries. Furthermore, the paper address memory limitation issue using techniques like transaction summarization. In order to track rw-independence, each transaction need to acquire lock which need to be stored until that transaction and all concurrent transactions commit. This might lead to unbounded memory requirement. Transaction summarization solves such problem by summarizing the state of multiple committed transactions into a more compact representation, at the cost of an increased false anomalies.

The main strength of the paper is identification of read-only transaction as the most common kind of transaction and optimizing for the most common cases. Their approach in balancing performance while maintaining serializability was as well insightful. In addition, the authors provided insightful examples at the beginning which explains their motivation clearly.

Although, the paper address important implementation issues, I found some limitations in the different techniques proposed. One limitation is the optimization addressed is for read-only intensive workloads. A significant fraction of OLTP based transactions include write/update operations. In addition, PosetgreSQL is a general database system which is supposed to work for various kind of workloads. As a result, they could have looked at a general solution which address workloads that are not read-only as well. Their solution still has additional overhead which includes lock management, anomalies detection, etc. I believe there is still room for optimization in these areas. Furthermore, their technique in handling deferrable transaction i.e long read-only transactions waiting for a safe snapshot, involves them waiting until all read/write transactions finish. This creates starvation which they claims rarely happens in the benchmark they considered. However, this argument fails to guarantee that starvation does not happen for other real world workloads.

Review 18

Paper focus and motivation
The purpose of this paper is to describe their experience implementing PostgreSQL's new serializable level, based on SSI technique. SSI stands for serializable snapshot isolation, where transactions have consistent view of the database during its period, but transactions between transactions may have different views concurrently and that allow some anomalies. SSI was newly invented and was never implemented in a production database release before. It is desirable to have true serializability and at the same time have low overhead and high concurrency. The authors decided to try this new technology out on PostgreSQL, an open source database, to see its performance and issues in implementation.

Design overview
SSI provides data consistency within the lifetime of each transaction. But certain anomalies are allowed. In the paper, along with the implementation of SI, algorithm has been designed to detect and prevent those anomalies. Instead of searching for cycles in serialization graph, the design aims at breaking the key elements of a cycle, which are adjacent rw anti-dependency edges, and they claimed that although false positives may happen, they are rare and the overhead reduction is huge.

According to their analysis and test, the performance is 7% less cost than snapshot isolation and is much better than traditional 2PL in terms of concurrency. Most of all, the design ensures true serializability.

Weakness and limitations
The paper claims that false positives in anomalies detection is low, and they showed us with some test and data. But it would be better to see some discussion about whether there is any other situations where false positives become big issues so that the user can avoid using this method.

Beyond the paper
The paper even push it further. They optimized the design for read only transactions so that once a safe snapshot for them is identified, all locking overhead of those read transactions will be removed.

Review 19

This paper describes serializable Snapshot Isolation and its implementation in PostgreSQL.
The authors successfully implemented serializable Snapshot Isolation (SSI) in PostgreSQL in a relatively inexpensive way and optimized read-only operation.
This paper starts with a discussion on snapshot isolation and serializability. One good thing about snapshot isolation is that it does not require read locking. And it uses multiversion concurrency control to recover from errors. This improves database’s performance. But some anomalies like Simple Write Skew and Batch processing problem could occur. So serializability will help.
Then SSI technique is introduced. It detects potential anomalies at runtime and abort transactions as necessary. By doing this, serializability under snapshot isolation is achieved. SSI is achieved by detecting “dangerous” r-w dependency.
The second part of this paper talks about read-only optimization that can be done using SSI implemented before. It identifies 1) a situation called safe-snapshots, 2) deferrable transactions. And use these two situations to improve read-only transaction performance.
After discussing SSI and read-only optimization, implementation details are given. Current PostgreSQL concurrency control methods are described. And conflicts detection, tracking and solving of SSI implementation are described. Then other topics such as memory usage about SSI implementation are covered.

This paper presented how to implement efficient SSI on a real world database system. It covers many detailed discussions about the implementation. This will also help us to understand what really matters when implementing features like SSI.
Another contribution is that it not only has coding part, but also has theory part. It made an extension of a theory.

Review 20

This paper talks about the idea of implementing Serializable snapshot isolation in PostGreSQL, a first time for a production database. The distinctive constraints that the authors were under seem to be the fact that PostgreSQL did not support any kind of 2PL lock so they could not leverage any of those features in order to implement serializable isolation. The authors have used SIREAD locks and a new lock manager that integrates with the remaining modules of PostGreSQL.

Serializable snapshot isolation uses the idea of preventing RW-antidependency. A rw-antidependency is caused if T1 writes a version of the object and T2 reads the previous version of the object and T1 appears to have executed after T2 because T2 did not see its update. This algoritm checks for a “dangerous” structure that involves two rw-antidependency edges being adjacent where the three transactions T1,T2,T3 are concurrent and T3 is the first to commit.

Since the focus is on reducing the memory overhead, and rw-antidependency seems to be the key anomaly for snapshot isolation, this algorithm does not keep track of wr and ww dependencies.

For this method, the authors have concentrated on improving performance for read-only transactions. They have used SIREAD locks that do not block conflicting writes but note a rw-antidependency in order to check for once the transaction has committed.

The safe retry seemed like a good idea to me where a transaction that is aborted in order to avert a dangerous structure when run again will not fail again with the same serialization failure. Another great contribution seems to be the fact that if a snapshot is taken when no read/write transactions are active, there is definitely less memory overhead since no SIREAD locks will be needed for that transaction.

One of the things I thought there could be an improvement on, is the availability of a safe snapshot with regards to the deferrable transaction. Since they cannot guarantee a safe snapshot in a reasonable time, I think by introducing a priority to the transactions involved in the concurrent transactions, starvation could be prevented. It seems to be that there is still a considerable amount of memory consumption and overhead since SIREAD locks and the committed transaction’s lists of rw-antidependencies can be discarded only when all transactions are committed so the aggressive cleanup may not be providing the kind of improvement that would make this method really great. Overall, I think this would be a great algorithm to be used in read-intensive databases where serialization may not be a necessity but would be a nice-to-have in a given situation.

Review 21

This paper mainly introduced the new level of isolation in the DBMS as SSI, and also the experience of implementing it in production PostgreSQl for the first time. Different from the traditional isolation levels, snapshot isolation is a new weak isolation level that is based on multiversion concurrency control, instead of read locking. Snapshot isolation avoids dirty reads, non-repeatable reads and phantom reads, but suffers from two other anomalies: simple write skew, and batch processing. SSL improves the isolation level by resolving the two anomalies in SI, and the major method used here is detecting possible cycles in the serialization history graph and retrying after abortion.

The anomalies in snapshot isolation arises from the wr-dependency, ww-dependency and rw-antidependency:

1. wr - if T1 writes a version of an object, and T2 reads from it, then T1 should execute before T2.
2. ww - if T1 writes a version of an object, and T2 replaces that with the next version, then T1 should execute before T2.
3. rw-anti - if T1 writes a version of an object, but T2 reads the version before T1’s modification, T2 should precede T1

In both of the simple write skew, and batch processing anomalies, there appear to be dangerous structure of two sequential rw-antidependency as T1-(rw)->T2-(rw)->T3. Hence the SSI would find possible dangerous structure using the combination of SIREAD lock and writer lock and abort one of the transactions in it to provide serializability.

Based on the above theory, the author implements SSI in PostgreSQl. And in the implementation process, more improvements and variants comes up.

1. if neither T1 or T2 commits before T2 in the dangerous structure, no false positive abortion is needed
2. safe-snapshot: if T1 is read only, and T1 snapshots before T3 commit, no false positive abortion is needed
3. Deferrable transactions: ensure complex read-only transactions always run on a safe sanpshot

To summarize, the SSL provides both high throughput of DBMS and serializability in transactions. With more optimization methods, it outperforms traditional 2PL on high ratio of read only data sets.

But there are still three potential drawback observed for SSL:

1. Significant performance improvement only show up in the in-memory configuration, how ever in reality not all enterprise level DBMS are run in small cluster of in-memory config.
2. It still requires the physical writer locks on each tuple, and keeping the modification info on each data entry would consume a lot more storage space.
3. tracking conflicts among good amount of concurrent transactions would post extra overhead, and hence may not be able to satisfy the need for large scale DBMS

Review 22

In this paper, it talks about the implement of serializable snapshot isolation in PostgreSQL.The serializable is a good property that it allows the application side think the transaction is serial and thus don’t need to consider the interaction among the transactions. As the 2PL is too expensive in PostgreSQL, it didn’t provide the serializable isolation previously. The PostgreSQL only provide the snapshot isolation which cannot guarantee serializable. These anomalies posed a dangerous threat to data integrity and hard to diagnose when the workload include ad hoc query. The paper talks about two examples, simple write skew and batch processing, which is not serializable under snapshot isolation.

SSI builds on SI and add anomaly check to ensure serializability. When find some transactions may violate the serializable, it will abort one transaction to avoid this. The paper talks about multiversion serialization graph which can represent the execution and if there is a cycle in the graph, the execution is not serializable. There are two ways to detect this anomalies one is to check the cycle(PSSI) but too expensive, another is check the dangerous structure and abort one of them.

Then the paper talks about the read-only optimization. As the long-running read-only transactions can increase the overhead of SSI, the paper introduce read-only snapshot ordering optimization to reduce the false-positive abort rate. The paper also talks about he safe snapshots and deferrable transactions to optimize the read-only transaction.

Then the paper talks about a lock manager built for SSI as there is no 2PL in the PostgreSQL previously, how to detect and track the conflict and retry a transaction that may not abort again to deal with the conflicts.

When the transaction holds many locks and keep for a long time, the memory usage would be very high. The paper talks about for strategy to deal with such situation. (1) safe snapshot and deferrable transaction; (2) granularity (3) cleanup unnecessary locks (4) summarizing committed transactions(cost more).

Later, the paper talks about their concern when implement because of the feature of PostgreSQL. It talks about the abort choice as two-phase commit, log-shipping replication cause unserializable and the savepoints and subtransactions.

In the end, the author evaluate the SSI in PostgreSQL compared to the SI and S2PL. It show the SSL can have similar performance as SI and much better than S2PL.

As the paper said, this is the first implementation of SSI in a production database release as well as the first in a database that did not previously have a lock-based serializable isolation level. This paper fully explains the considerations during their development and why they concern about this.

In the evaluation part, the paper should introduce more about the benchmark and why the benchmark can reflect the performance of the SSI. As their are many concern when implement the SSI in PostgreSQL(e.g. memory limitation, read-only optimization), it would be better to see how each optimization influence the performance of SSI in PostgreSQL.

Review 23

The paper describes why and how Serializable Snapshot Isolation was added to PostgreSQL. The authors provide background on the different kinds of concurrency issues that may occur in transactions generally, as well as specifically with (regular) Snapshot Isolation. They also provide background to describe a mechanism with which a subset of transactions can be executed using Snapshot Isolation which still ensuring serializability. In their evaluation, the paper demonstrates that Serializable Snapshot Isolation performs similarly to Snapshot Isolation and regularly achieves over 90% of the performance of Snapshot Isolation. Compared to Strict Two-Phase Locking, Serializable Snapshot Isolation performs up to 4 times as well, usually with a more modest performance increase, but the benefit is substantial.

This paper did a good job of providing background. It had an appropriately thorough discussion of conflict types, theoretical background for optimizations, previous work on SSI, and PostegreSQL. Additionally, I felt that this paper was complete in the sense that it described a full implementation that handled all the corner cases experienced by a real DBMS. I did not like how the authors used different systems to run different benchmarks as it could be skewing the results to look more favorable for their work. They should have reported data collected from a single system.

Review 24

This paper describes an extension on top of snapshot isolation called serializable snapshot isolation (SSI) and how it was integrated into PostgreSQL. The main problem of snapshot isolation is that it could leave a database in an inconsistent state if it encounters an SI anomaly. The main problem of S2PL is that it is a pessimistic approach that sometimes locks when unnecessary, decreasing throughput. Therefore, SSI provides a solution that is faster than S2PL but also ensures serializability.

The authors first introduce the anomalies possible with SI: wr-dependencies, ww-dependencies, and rw-antidependencies. Then they prove that in SSI, every serialization anomaly has structure as follows: T1 has a rw-antidependency with T2 and T2 has a rw-antidependency with T3. In this case, if T3 is the first to commit, the database will be inconsistent.

When a dangerous structure is found, SSI will abort one of the transactions using the safe retry method, which will ensure that the transaction will not fail in the same way again. To do this, we will 1) not abort anything until T3 commits, 2) always try to abort T2 first if possible and 3) abort T1 if both T2 and T3 have been committed.

Overall, the paper presents a new concept that has advantages over the traditional S2PL and has very good real world experiments to back up its claims. However, there are some weaknesses with the paper:

1. What are the memory implications of using SSI with PostgreSQL? I would have liked to see a comparison with regular SI and with S2PL. For some systems, the memory usage increase may not be worth the speed up.
2. The authors mention that PSSI could be used to eliminate all false positives with cycles, but that it is not necessary because it uses more memory and the serialization failure rate is well under 1%. Are there any types of workloads that would benefit from PSSI though? Can database administrators choose to use PSSI instead of just SSI if it would help their specific use case?

Review 25

This paper discusses the implementation of a truly serializable isolation level in PostgreSQL. True Serializability can be very difficult to implement, as a DBMS must protect against anomalies such as dirty reads, phantom reads, and non-repeatable reads, which are specified in the ANSI SQL standard, as well as anomalies such as wimple write skew and batch processing. Strict 2 phase locking schemes can be modified to prevent these additional anomalies, but the required modifications can have a significant performance cost. Additionally PostgreSQL implements snapshot isolation, so introducing 2PL protocols would be a significant investment. This paper is chiefly concerned with developing a serializable snapshot isolation mode capable of recognizing and addressing these anomalies.

Anomalies can occur when :

1) There is a sequence of transactions such that there is an RW conflict from T1 -> T2 and an RW conflict from T2->T3
2) T1 is concurrent with T2, and T2 is concurrent with T3
3) Some conflict exists from T3->T1
4) T3 is the first transaction in the cycle to commit

Serializable Snapshot Isolation prevents these anomalies by maintaining data about RW conflicts between concurrent transactions. Rather than maintaining a complete conflict graph, PostgreSQL tracks when “dangerous structures” comprising two adjacent RW edges arise, then aborts one of the relevant transactions. This prevents any potential anomalies from occurring by breaking up a graph before a cycle can form. This method of resolution leads to some false positives, but the research team determined that the effect of these false positive on performance was negligible. Long-running transactions can cause conflict data to be preserved in memory for long periods of time, so PostgreSQL implements aggressive cleanup and summarization of conflict data in order to limit memory usage.

PostgreSQL also implements “safe snapshots”, which is a snapshot taken when no concurrent read/write transaction has committed with a RW conflict to a transaction that has committed before T’s snapshot is taken. PostgreSQL implements deferrable transactions as a method of speeding up read-only queries. Deferrable transactions wait for a safe snapshot to be taken, then are allowed to run without keeping track of SIREAD locks, since no RW conflicts can be formed in this scenario.

My chief concern with this paper is the misrepresentation of the transaction rate for the S2PL scheme. The authors do state that the data for the S2PL scheme is based on a simple implementation of S2PL, but they also call attention to the vast performance increase of SSI and SI over S2PL. A more robust implementation of S2PL developed and optimized by a DBMS using it as their primary isolation scheme would almost certainly exhibit higher performance that the rudimentary version put together by PostgreSQL for testing purposes. It would have been nice to see that acknowledged more clearly, as a reader skimming the paper could easily infer that S2PL is much more inefficient than it truly is.

Review 26

This paper implemented a new PostgreSQL serializable snapshot isolation level based on PostgresSQL’s snapshot isolation. Serializable isolation is an important property for transactions that can allow developers to write transactions as though they will execute sequentially. However, PostgreSQL only supported snapshot isolation, which allowed some anomalies between transactions. Therefore, this paper proposed its implementation of serializable snapshot isolation in PostgreSQL, and compared its performance with other concurrency mechanisms.

The paper talked about some important challenges the authors overcame, including the implementation of a new lock manager, ensuring memory usage bound, and integration with other PostgreSQL features. First, PostgreSQL did not support serializable isolation, while MySQL supported 2-phase lock mechanism. Thus, the authors had to build a new lock manager. Second, long-running transaction has potentially unbounded memory usage. The authors provided some techniques dealing with it, including safe snapshots, deferrable transactions, aggressive cleanup, and summarization. Third, the implementation of serializable snapshot isolation integrated SSI with PostgreSQL’s features such as replication systems, 2-phase commit and subtransactions. Last, this paper compared the performance of SSI with other concurrency mechanisms, and indicated that SSI outperforms many traditional concurrency approaches such as 2-phase locking.

The strength of this paper is that it mentioned many challenges and their approaches to deal with these challenges during the implantation of SSI. This would make readers follow their flow of implementation. In addition, the paper provided sufficient experimental results to propose the performance of SSI.

The weakness of this paper is that it did not provide examples when explaining the topics in each section. This would make the paper harder to understand, especially when talking about transactions.

To sum up, this paper talked about the experience of their implementation of a new PostgreSQL serializable snapshot isolation level based on PostgresSQL’s snapshot isolation, and provided another isolation level for PostgreSQL users. It is particularly important in today’s highly-concurrent systems.

Review 27

This paper was about integrating Serializable Snapshot Isolation (SSI) into PostgreSQL. SSI is an important abstraction for application developers that allows them to not worry about transaction concurrency because the system will take care of serializing transactions. This allows developers to write transactions as if they are the only thing occurring on the system at that time, which thus makes them far easier to develop. Until recently (when this paper was written) PostgreSQL did not have support for SSI, and this paper compared how theirs compared to the recently implemented version of S2PL on PostgreSQL.

A large part of this paper was looking at dependency graphs and finding observations about what order certain dependencies go in and finding out ways to relieve them. If there is a cycle in the dependency graph then it does not correlate to a serial ordering of the transactions. If you are able to reorder transactions without a cycle you have found a serial scheduling of the transactions.

This paper came up with 3 theorems regarding transaction scheduling to help with serializibility.
1.) Every cycle in the serialization history graph contains a sequence of edges T1(rw)→T2(rw)→T3 where each edge is a rw-antidependency. Furthermore,T3 must be the first
transaction in the cycle to commit.
2.) Transaction T1is concurrent with T2, and T2 is concurrent withT3, because rw-antidependencies occur only between concurrent transactions.
3.) Every serialization anomaly contains a dangerous structure T1(rw)→T2(rw)→T3, where if T1 is read-only, T3must have committed before T1took its snapshot.

I think this paper could have benefitted from more visual representations describing their theories. I personally find it really helpful to look at the dependency graphs and the transaction logs and this paper would have made much more sense to me if there were more of those to help describe it.

The paper did have impressive results though as their version was much more efficient than S2PL that was currently implemented on PostgreSQL for serializability. This was not a surprise to me because of how intricate and complicated their solution was. The clear tradeoff is S2PL is very easy to understand and explain, but lacks some of the performance benefits SSI offers because of that simplicity. If I were a DBA I would have considered switching to this instead of S2PL.

Review 28

In PostgreSQL, before the implementation described in this paper, there was no optional functionality for a serializable isolation level. Instead, what was offered was “snapshot isolation,” which offered better performance than 2-phase locking but didn’t always offer true serializability between transactions in certain cases. Because this may not be sufficient for all DBMS’s, the authors were motivated to work on implementing “serializable snapshot isolation” (SSI). With SSI, the performance benefits of snapshot isolation could be retained, while still offering true serializability.

The main innovation behind serializable snapshot isolation is the implementation of a serialization graph between transactions. If read-write conflicts are detected as adjacent edges in the graph, a transaction is aborted and potentially retried. However, in order to detect conflicts between updates and reads, SSI implementations have previously relied on profiling read locks from the lock manager. Thus the authors built a new lock manager to track read dependencies. It uses locks of differing granularity, which does not block transactions from conflicts, but instead flags the conflicts (resulting in fewer deadlocks). Their performance was impressive, offering the advantage of serializability with performance comparable to snapshot isolation, and performing better than 2PL in read-heavy workloads.

One interesting question that could be raised is towards the choice of PostgreSQL versus other systems. Are there advantages to implementing SSI in PostgreSQL, or is it one of the only systems that lacks some version of SSI? If other systems had comparable implementations, seeing a comparison would probably provide much more insight into the optimality of their technique.

Review 29

Snap shot isolation allows efficient concurrency control, however it does allow for some anomalies. While this may work for most use cases, some such as the Wisconsin Court System need absolute guarantees on data integrity.This paper is unique because it implements the Serializable Snapshot Isolation technique to solve anomaly problems rather than the widely used S2PL scheme. SSI takes the simple idea of snapshot isolation and extends it to check if the possibility for anomalies exist.

The key insights in this paper were the additional read only-optimizations implemented. The first optimization realized is in the scenario where a serialization anomaly exists in a serialization history graph in the form T1 -> T2 -> T3 where T1 is read only. Since a cycle exists, there must be another transaction Tx that precedes T1. Tx’s changes must be visible to T1 for there to be a cycle, thus T3 must commit before t0 commits and before T1 takes its snapshot. Intuitively, this means that read-only transactions only need to be worried about the time of their snapshots, not their commits. The second optimization is realized by noting that a read-only transaction T1 can only be apart of a dangerous structure if it conflicts with a r/w transaction T2 and T2 conflicts with another transaction T3 that commits before T1’s snapshot. With this realization, standard snapshot isolation can be used on such read-only transactions without anomaly issues.

The largest draw back of this paper was its lack of data for the presented optimization techniques. Specifically, for the identification of read-only transactions that can be run using standard snapshot isolation. No discussion is provided to quantify how many such transactions can potentially be identified and generally how effective the method was. There is also no discussion quantifying how much overhead is incurred to realize such an optimization.

Review 30

This paper explains the implementation of Serializable Snapshot Isolation (SSI) in PostgreSQL 9.1. release. For performance reasons, previous PostgreSQL versions used snapshot isolation instead of blocking technique. However, snapshot isolation causes several anomalies that poses danger to data integrity. The SSI allows application developers to write transaction as though they will execute sequentially, without regard for interactions with concurrently-existing transactions. Since the SSI is developed based on snapshot isolation, it maintains many of the predecessor’s benefit while guaranteeing serializability. The SSI runs transactions using snapshot isolation, but adds additional checks to determine whether anomalies are possible without requiring additional blocking.

The paper starts with comparing snapshot isolation with serializability, explaining the downside of snapshot isolation technique and why serialiability is important. The paper then continues with the explanation on how SSI detects “dangerous structures” that forms from three kinds of anomalies: wr-dependencies, ww-dependencies, and rw-antidependencies. Among these three, SSI mostly concerns with rw-antidependencies (identified using SIREAD locks). A variant of SSI technique is PSSI (Precisely Serializable Snapshot Isolation). The SSI also implements read only optimization using safe snapshots (to ensure that no concurrent read/write transactions has committed with rw-antidependencies) and deferrable transactions (to ensure read-only transactions run using safe snapshot) so that read-only transactions can run without the fear of dangerous structures. The paper goes on about PostgreSQL’s concurrency control mechanism, including conflict detections by implementing SSI Lock Manager, conflict tracking, and conflict resolution. Then, it explains the memory usage mitigation to limit the memory usage of the SSI Lock Manager (using safe snapshot, granularity promotion, aggressive cleanup, and summarization of committed transaction). Then, it explains how SSI interacts with PostgreSQL features: two-phase commit, streaming replication savepoints and subtransactions, and index types. Last, it provides the performance evaluation from three workloads: SIBENCH Microbenchmark, DBT-2++, and RUBiS.

The main contribution of this paper is that this is the first implementation of SSI in production database release and so it addresses the interaction of the SSI with other database features. Previous papers usually tested the implementation of SSI in isolated environment, not production environment. Besides presenting the benefit of SSI, it also presents the challenges in implementing SSI in PostgreSQL, for example predicate locks that tracks dependencies and transaction summarizations to bound memory usage.

However, the SSI techniques depends a lot o transaction abortion to prevent dangerous structure from forming. It does have safe retry feature, but the paper never really explains how the significant addition of abort operations affect the performance compared to the snapshot isolation technique. Some comparison between PostgreSQL’s features before and after SSI would also help.

Review 31

The purpose of this paper is to describe the new serializable snapshot isolation level (SSI) that has recently ( the paper was published in 2012) been integrated into PostgreSQL 9.1. This is important because this marks the first time that SSTI has been implemented in a production database release, and they present their challenges and results from implementation. It is also important because historically PostgreSQL did not provide serializability of transactions, and this improves upon the previously offered highest isolation level (which was snapshot isolation). They are also presenting the first SSI system to be used in production (of a commercial DBMS).

The technical contributions of this paper are numerous. First of all, they describe why using SSI to ensure serializable transactions helps by allowing database users to worry less about concurrency issues in their system. Additionally, they offer several new theoretical results regarding the discovery and monitoring of conflicts ,specifically rw-antidependencies in concurrent transactions. They provide more effective tracking of such serialization anomalies so that snapshot isolation can be used in more cases where they can make a theoretical guarantee that known anomalies that can occur in SSI do not occur. They also detail some interesting (and some unexpected) interactions between SSI and existing PostgreSQL features that must be accounted for in a commercial deployment. For example, their system is forced to make assumptions on aborted transactions due to the two-phase commit properties of PostgreSQL.

I think the strengths of this paper are in its detail and rigor. We have not read many database papers that involve proves, and I think that this paper really leverages theoretical results. The proofs allow the reader (and the database community at large) to be convinced of the lack of anomalies present in the system, which is important for large deployments of commercial databases.

As far as weaknesses go, in the results section of this paper, I don’t believe that the authors do a sufficient job of discussing counter-intuitive results in their data. They tend to point out trends that wouldn’t be expected, but do not offer any explanation, even a speculative one, as to why these results might have occurred.

Review 32

Paper Title: Serializable Snapshot Isolation in PostgreSQL
Reviewer: Ye Liu

Paper Summary:
This paper presents the implementation details of PostgreSQL’s serializable isolation level. The unique characteristics about this implementation is that it is the first of SSI in a production database release and that it is the first implementation in a database without a previously installed lock-based serialization isolation level. In details this paper focuses on some problem-solving while implementing the serialization isolation level as well as evaluates the performance of the implementation.

The implementation presented in this paper comes with some overhead in running time. However the advantages are that it performances with a higher transaction rate (efficiency) and thus a higher throughput. In short, the gain/strength of the presented method is that the implementation enables the DBMS with a more efficiency parallelization mechanism.

In details the paper described the locking mechanism used in this implementation, which is the predicate lock. When it comes to such situations when some “predicative” decisions have to be made and a false prediction comes with costs, such as roll back, it would be interesting to have some sort of memorizing mechanism to keep a record of successes and failures. In this way some learning algorithm may be applied to adjust the rules used for making such predictions so that the longer the system runs, the better the performance will be regarding to the predicted decisions.

In section 5.4 the paper mentions that the safe retry rule is enforced in this implementation. This is a design choice that sacrifices efficiency for safety. In such cases, it would be a natural question to ask, if there is a better way to minimize the sacrifice. An advantage of this implementation is that this safe rule is only applied when a “dangerous” structure is found. However it would be more informative if the author provided some statistics such as how often are those “dangerous structures” occur.

Paper Title: Serializable Snapshot Isolation in PostgreSQL
Reviewer: Ye Liu

Paper Summary:
This paper presents the implementation details of PostgreSQL’s serializable isolation level. The unique characteristics about this implementation is that it is the first of SSI in a production database release and that it is the first implementation in a database without a previously installed lock-based serialization isolation level. In details this paper focuses on some problem-solving while implementing the serialization isolation level as well as evaluates the performance of the implementation.

Paper Details:
The implementation presented in this paper comes with some overhead in running time. However the advantages are that it performances with a higher transaction rate (efficiency) and thus a higher throughput. In short, the gain/strength of the presented method is that the implementation enables the DBMS with a more efficiency parallelization mechanism.

In details the paper described the locking mechanism used in this implementation, which is the predicate lock. When it comes to such situations when some “predicative” decisions have to be made and a false prediction comes with costs, such as roll back, it would be interesting to have some sort of memorizing mechanism to keep a record of successes and failures. In this way some learning algorithm may be applied to adjust the rules used for making such predictions so that the longer the system runs, the better the performance will be regarding to the predicted decisions.

In section 5.4 the paper mentions that the safe retry rule is enforced in this implementation. This is a design choice that sacrifices efficiency for safety. In such cases, it would be a natural question to ask, if there is a better way to minimize the sacrifice. An advantage of this implementation is that this safe rule is only applied when a “dangerous” structure is found. However it would be more informative if the author provided some statistics such as how often are those “dangerous structures” occur.

Review 33

This paper introduces the implementation of Serializable Snapshot Isolation on PostgreSQL. It gives detail introduction on the implementation as well as the background knowledge of the Snapshot Isolation and Serializable Snapshot Isolation. It explains the difference between serializability and snapshot isolation, and pointed out that SI could cause unexpected behavior because of lost update issue. It give the example of simple write skew and issues in batch processing to illustrate this point. Moreover, it also introduces many techniques used to prevent such anomalies in SI, including materialized conflict and integrity constraint. It then introduces serializable Snapshot Isolation. Different than SI, it adds checks to determine whether anomalies are possible and abort for those who violate serializability. It also introduce the read-only optimization that originally introduced by this paper which utilized a serializable theory to provide read-only snapshot ordering as well as to reduce the false positive abort rate. It introduces safe snapshots and deferrable transactions that don't have to acquire a SIREAD locks and can substantially improve the performance of these two scenarios. It also introduces the memory mitigation of the system, and introduces the techniques to prevent unbounded memory usage, including aggressive cleanup of committed transactions and summarization of committed transactions. At the end of this paper, it introduces the feature integration and also gives a complete evaluation on the performance with several third-party benchmarks.

1. It first introduce the SSI to a widely deployed developing DBMS system, and show that SSI can substantially improve the performance as well as provide better consistency to the system.
2. It also gives details introduction of the implementation details as well as the background and theoretical approach of its implementation, which helps its reader to understand the concepts clearly.

1. As it states in the paper, there are two overhead of SSI, one i the work on tracking dependency and the other is on aborted retires. These two overhead are extremely critical on large scale heavy transactional workloads. However, the paper only conduct experiments on a DBT-2++ benchmark instead of the real world problem, which I believe is not enough. Further research on the overhead may be needed.
2. Although it uses several strategies to constraint the memory usage, there is still possibility that a heavy transaction workload may cause an unbounded memory usage problem. I think a better approach would be a Garbage Collection algorithm, which keeps track of the memory and the system, as it shows in the paper of H-store.

Review 34

This paper summarizes the work of applying Serializable Snapshot Isolation(SSI) technique in PostgreSQL database. Previously PostgreSQL didn’t provide real serializable isolation level as the traditional Strict Two-Phase Locking(S2PL) introduces large overhead that is not acceptable. Instead, PostgreSQL provides Snapshot Isolation level, a weaker serialization with greater performance. In this paper, this problem is addressed by introducing Serialization Snapshot Isolation(SSI), which guarantees full serializability without much overhead compared to Snapshot Isolation. In Snapshot Isolation level, anomaly can happen when there is a cycle in serialization graph. The previous work carefully studied these anomalies and discovered that they happen when there is dangerous structures such that T1 rw-antidependent on T2 and T2 rw-antidependent on T3 (Here T1 is read-only, T3 commits before T1 took its snapshot). Therefore SSI prevent anomalies in Snapshot Isolation by adding additional checks to determine if there is such dangerous structure. If a transaction has both incoming and outgoing rw-antidependency, SSI will abort one of the involved transactions.

Then main contribution of this work is achieving real serialization in PostgreSQL. This enables PostgreSQL developers work in a simpler concurrency model and ignore serializability issues. This implementation also effectively limits the system overhead by optimizing for read-only transactions and developing transaction summarization methods. The serialization are welcome, but users are unwilling to pay performance penalty for this simplicity. The comparable performance of SSI approach to Snapshot Isolation is a great advantage that can hopefully make this implementation successful.

One weakness of this paper is that lacking of performance analysis on write-heavy workload. Though this work is mainly optimized for read-heavy applications, It would be more feasible if the authors can show us the amount of transaction aborts are not significantly in write transactions. Moreover, even in read heavy load, the amount of write transactions could be large(though the portion may still be small). The authors should justify that transaction aborts will not grow exponentially with respect to write transactions. Another concern is that limiting the memory usage in lock manager can potentially increase transaction aborts. The exact relation here is not well studied in the paper.