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