> Before understanding how postgres implements the serializable isolation > level (I have see many paper related to it), I have question about how it > should be. > > > I mainly read the ideas from > https://www.postgresql.org/docs/11/transaction-iso.html. > > > In fact, this isolation level works exactly the same as Repeatable Read > except that it monitors for conditions which could make execution of a > concurrent set of serializable transactions behave in a manner inconsistent > with all possible serial (one at a time) executions of those transactions. > > > in repeatable read, every statement will use the transaction start > timestamp, so is it in serializable isolation level? > > > When relying on Serializable transactions to prevent anomalies, it is > important that any data read from a permanent user table not be considered > valid until the transaction which read it has successfully committed. This > is true even for read-only transactions ... > > > What does the "not be considered valid" mean? and if it is a read-only > transaction (assume T1), I think it is ok to let other transaction do > anything with the read set of T1, since it is invisible to T1(use the > transaction start time as statement timestamp).
There are some test cases and link to the paper explaining read-only transaction anomaly in the source tree. src/test/isolation/specs/read-only-anomaly-2.spec Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
