Serialization questions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Serialization questions

Alex-12

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). 


Thanks


Reply | Threaded
Open this post in threaded view
|

Re: Serialization questions

Alex-12


On Tue, Aug 20, 2019 at 4:47 PM Alex <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Serialization questions

Tatsuo Ishii-3
In reply to this post by Alex-12
> 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


Reply | Threaded
Open this post in threaded view
|

Re: Serialization questions

Richard Guo-2
In reply to this post by Alex-12

On Wed, Aug 21, 2019 at 9:30 AM Alex <[hidden email]> wrote:

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  


This behavior makes sense to me. The effect can be considered as we
 execute the two sessions in a serial order of first session 1 and then
 session 2.

Thanks
Richard