Re: [PATCH] two minor fixes to MVCC docs

My apologies for not processing your December patch earlier, and I just
saw your partial patch post today. Applied to master and PG 15 where
MERGE was added.

---------------------------------------------------------------------------

On Wed, Dec 28, 2022 at 04:02:58PM -0800, Will Mortensen wrote:
> Fix markup indentation and add a mention of MERGE.

> From 46977fbe5fa0a26ef77938a8fe30b9def062e8f8 Mon Sep 17 00:00:00 2001
> From: Will Mortensen <will(at)extrahop(dot)com>
> Date: Sat, 27 Aug 2022 17:07:11 -0700
> Subject: [PATCH 1/6] doc: fix markup indentation in MVCC
>
> ---
> doc/src/sgml/mvcc.sgml | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
> index 337f6dd429..69b01d01b9 100644
> --- a/doc/src/sgml/mvcc.sgml
> +++ b/doc/src/sgml/mvcc.sgml
> @@ -109,8 +109,8 @@
> dirty read
> <indexterm><primary>dirty read</primary></indexterm>
> </term>
> - <listitem>
> - <para>
> + <listitem>
> + <para>
> A transaction reads data written by a concurrent uncommitted transaction.
> </para>
> </listitem>
> @@ -121,8 +121,8 @@
> nonrepeatable read
> <indexterm><primary>nonrepeatable read</primary></indexterm>
> </term>
> - <listitem>
> - <para>
> + <listitem>
> + <para>
> A transaction re-reads data it has previously read and finds that data
> has been modified by another transaction (that committed since the
> initial read).
> @@ -135,8 +135,8 @@
> phantom read
> <indexterm><primary>phantom read</primary></indexterm>
> </term>
> - <listitem>
> - <para>
> + <listitem>
> + <para>
> A transaction re-executes a query returning a set of rows that satisfy a
> search condition and finds that the set of rows satisfying the condition
> has changed due to another recently-committed transaction.
> @@ -149,8 +149,8 @@
> serialization anomaly
> <indexterm><primary>serialization anomaly</primary></indexterm>
> </term>
> - <listitem>
> - <para>
> + <listitem>
> + <para>
> The result of successfully committing a group of transactions
> is inconsistent with all possible orderings of running those
> transactions one at a time.
> --
> 2.25.1
>

> From 7eaec62fd8665ba761114e8238f95f0f47924a21 Mon Sep 17 00:00:00 2001
> From: Will Mortensen <will(at)extrahop(dot)com>
> Date: Sat, 27 Aug 2022 17:54:11 -0700
> Subject: [PATCH 2/6] doc: add mention of MERGE in MVCC
>
> ---
> doc/src/sgml/mvcc.sgml | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
> index 69b01d01b9..512e8b710d 100644
> --- a/doc/src/sgml/mvcc.sgml
> +++ b/doc/src/sgml/mvcc.sgml
> @@ -1750,9 +1750,9 @@ SELECT pg_advisory_lock(q.id) FROM
> changes in the table. A repeatable read transaction's snapshot is actually
> frozen at the start of its first query or data-modification command
> (<literal>SELECT</literal>, <literal>INSERT</literal>,
> - <literal>UPDATE</literal>, or <literal>DELETE</literal>), so
> - it is possible to obtain locks explicitly before the snapshot is
> - frozen.
> + <literal>UPDATE</literal>, <literal>DELETE</literal>, or
> + <literal>MERGE</literal>), so it is possible to obtain locks explicitly
> + before the snapshot is frozen.
> </para>
> </sect2>
> </sect1>
> --
> 2.25.1
>

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Only you can decide what is important to you.