Horton

Re: Potential G2-item cycles under serializable isolation

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Kyle Kingsbury <aphyr@jepsen.io>, Peter Geoghegan <pg@bowt.ie>, Kevin Grittner <kgrittn@gmail.com>, Jeff Davis <pgsql@j-davis.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2020-06-11T19:30:23Z
Lists: pgsql-bugs 
Hi,

On 2020-06-11 17:40:55 +1200, Thomas Munro wrote:
> +   <para>
> +    The Repeatable Read isolation level is implemented using a technique
> +    known in academic database literature and in some other database products
> +    as <firstterm>Snapshot Isolation</firstterm>.  Differences in behavior
> +    may be observed when compared with systems using other implementation
> +    techniques.  For a full treatment, please see
> +    <xref linkend="berenson95"/>.
> +   </para>

Could it be worthwhile to narrow the "differences in behaviour" bit to
read-write transactions? IME the biggest reason people explicitly use RR
over RC is to avoid phantom reads in read-only transactions. Seems nicer
to not force users to read an academic paper to figure that out?


> @@ -1726,6 +1744,13 @@ SELECT pg_advisory_lock(q.id) FROM
>      see a transient state that is inconsistent with any serial execution
>      of the transactions on the master.
>     </para>
> +
> +   <para>
> +    Access to the system catalogs is not done using the isolation level
> +    of the current transaction.  This has the effect that newly created
> +    database objects such as tables become visible to concurrent Repeatable
> +    Read and Serializable transactions, even though their contents does not.
> +   </para>
>    </sect1>

Should it be pointed out that that's about *internal* accesses to
catalogs? This could be understood to apply to a SELECT * FROM pg_class;
where it actually doesn't apply?

Greetings,

Andres Freund

Commits

  1. Doc: Add references for SI and SSI.

  2. Improve comments for [Heap]CheckForSerializableConflictOut().

  3. Avoid update conflict out serialization anomalies.

  4. Implement genuine serializable isolation level.