On Tue, Aug 20, 2019 at 4:47 PM Alex <zhihui.fan1...@gmail.com> wrote:
> 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). > first issue "set default_transaction_isolation to 'serializable';" on the both sessions, then run: Session 1: begin; select * from t; (2 rows selected); Session 2: delete from t; (committed automatically) Session 1: commit; (commit successfully). looks the reads in session 1 has no impact on the session 2 at all which is conflicted with the document > Thanks >
