From: | Alex <zhihui(dot)fan1213(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Serialization questions |
Date: | 2019-08-21 01:21:48 |
Message-ID: | CAKU4AWrH2jS-KHL4uhjtiEvdLYFyoMdYn72-RiAaxDDn-G3eig@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 20, 2019 at 4:47 PM Alex <zhihui(dot)fan1213(at)gmail(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Barwick | 2019-08-21 01:25:40 | Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions |
Previous Message | Andres Freund | 2019-08-20 23:06:46 | Re: REL_12_STABLE crashing with assertion failure in ExtractReplicaIdentity |