Date: Wed, 23 Nov 2022 02:17:19 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Erik Rijkers <er@xs4all.nl>, Laurenz Albe <laurenz.albe@cybertec.at>,
	Robert Treat <rob@xzilla.net>,
	Simon Riggs <simon.riggs@enterprisedb.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	pgsql-hackers@postgresql.org
Subject: Re: New docs chapter on Transaction Management and related changes
Message-ID: <20221123081718.GI11463@telsasoft.com>
References: <Y0tZf7N+cUJ9ebPI@momjian.us>
 <80a5fd9c080d66e62f90c9565e3e1b54e61f584c.camel@cybertec.at>
 <CANbhV-GafnnLmyMmjwYGFFcspk_twoEO56M3jiB7D0p_TkUmZA@mail.gmail.com>
 <3603e6e85544daa5300c7106c31bc52673711cd0.camel@cybertec.at>
 <CAJSLCQ0fH4Jt0yiJVbXmCmJUYP4h4fXzoyiUU6Nxva4KWGZG6A@mail.gmail.com>
 <Y3fc6SqY3dG2Qd2x@momjian.us>
 <07d63204be526d4c74c322c3f1646e76e5ba3910.camel@cybertec.at>
 <Y30OIdpiq5ol8mF8@momjian.us>
 <1806c06d-1bc2-3b44-d722-fcecf02981e0@xs4all.nl>
 <Y30Z/AddvUCzH6OA@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y30Z/AddvUCzH6OA@momjian.us>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20221123081718.GI11463%40telsasoft.com>
Precedence: bulk

On Tue, Nov 22, 2022 at 01:50:36PM -0500, Bruce Momjian wrote:
> +
> +  <para>
> +   A more complex example with multiple nested subtransactions:
> +<programlisting>
> +BEGIN;
> +    INSERT INTO table1 VALUES (1);
> +    SAVEPOINT sp1;
> +    INSERT INTO table1 VALUES (2);
> +    SAVEPOINT sp2;
> +    INSERT INTO table1 VALUES (3);
> +    RELEASE SAVEPOINT sp2;
> +    INSERT INTO table1 VALUES (4))); -- generates an error
> +</programlisting>
> +   In this example, the application requests the release of the savepoint
> +   <literal>sp2</literal>, which inserted 3.  This changes the insert's
> +   transaction context to <literal>sp1</literal>.  When the statement
> +   attempting to insert value 4 generates an error, the insertion of 2 and
> +   4 are lost because they are in the same, now-rolled back savepoint,
> +   and value 3 is in the same transaction context.  The application can
> +   now only choose one of these two commands, since all other commands
> +   will be ignored with a warning:
> +<programlisting>
> +   ROLLBACK;
> +   ROLLBACK TO SAVEPOINT sp1;
> +</programlisting>
> +   Choosing <command>ROLLBACK</command> will abort everything, including
> +   value 1, whereas <command>ROLLBACK TO SAVEPOINT sp1</command> will retain
> +   value 1 and allow the transaction to continue.
> +  </para>

This mentions a warning, but what happens is actually an error:

postgres=!# select;
ERROR:  current transaction is aborted, commands ignored until end of transaction block