Document How Commit Handles Aborted Transactions
Hi,
The commit reference page lacks an "Outputs" section even though it is
capable of outputting both "COMMIT" and "ROLLBACK".
The attached adds this section, describes when each applies, and then
incorporates the same into the main description for commit as well as the
transaction section of the tutorial - which presently seems to be the main
discussion area for the topic (the Concurrency Control chapter lacks a
section for this introductory material).
This was noted as being needed by Tom Lane back into 2006 but it
never happened.
/messages/by-id/28798.1142608067@sss.pgh.pa.us
It came up again when I was answering a question on Slack regarding "commit
and chain" wondering whether the "and chain" could be made conditional
(i.e., could the new transaction start aborted) on whether commit outputted
"commit" or "rollback".
Its left implied that this behavior of "rollback" is standard-conforming.
Please feel free to suggest/add language to the Compatibility section if
this is not the case.
David J.
Attachments:
0001-doc-Commit-performs-rollback-of-aborted-transactions.patchtext/x-patch; charset=US-ASCII; name=0001-doc-Commit-performs-rollback-of-aborted-transactions.patchDownload
From f9c40e72c8e62ae7b364a82d26a0f73995ef5082 Mon Sep 17 00:00:00 2001
From: "David G. Johnston" <David.G.Johnston@Gmail.com>
Date: Fri, 20 Dec 2024 08:40:47 -0700
Subject: [PATCH] doc: Commit performs rollback of aborted transactions
The Commit command handles an aborted transaction in the same
manner as the Rollback command. This needs to be documented.
Add it to both the reference page as well mentioning the behavior
in the official material for introducting transactions - the tutorial.
In passing, make the description of the Commit reference page
self-contained by mentioning the 'and chain' behavior.
---
doc/src/sgml/advanced.sgml | 18 +++++++++++++++---
doc/src/sgml/ref/commit.sgml | 33 +++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml
index 755c9f1485..b5cae2335c 100644
--- a/doc/src/sgml/advanced.sgml
+++ b/doc/src/sgml/advanced.sgml
@@ -149,7 +149,8 @@ DETAIL: Key (city)=(Berkeley) is not present in table "cities".
systems. The essential point of a transaction is that it bundles
multiple steps into a single, all-or-nothing operation. The intermediate
states between the steps are not visible to other concurrent transactions,
- and if some failure occurs that prevents the transaction from completing,
+ and if <link linkend="tutorial-transactions-aborted">some failure</link>
+ occurs that prevents the transaction from completing,
then none of the steps affect the database at all.
</para>
@@ -218,7 +219,8 @@ UPDATE branches SET balance = balance + 100.00
<para>
In <productname>PostgreSQL</productname>, a transaction is set up by surrounding
the SQL commands of the transaction with
- <command>BEGIN</command> and <command>COMMIT</command> commands. So our banking
+ <xref linkend="sql-begin"/> and
+ <xref linkend="sql-commit"/> commands. So our banking
transaction would actually look like:
<programlisting>
@@ -233,7 +235,7 @@ COMMIT;
<para>
If, partway through the transaction, we decide we do not want to
commit (perhaps we just noticed that Alice's balance went negative),
- we can issue the command <command>ROLLBACK</command> instead of
+ we can issue the command <xref linkend="sql-rollback"/> instead of
<command>COMMIT</command>, and all our updates so far will be canceled.
</para>
@@ -256,6 +258,16 @@ COMMIT;
</para>
</note>
+ <para id="tutorial-transactions-aborted">
+ When a failure does occur during a transaction it is not ended but instead
+ goes into an aborted state. While in this state all commands except
+ <xref linkend="sql-commit"/> and <xref linkend="sql-rollback"/> are ignored and,
+ importantly, both those commands behave identically - they roll-back and close
+ the current transaction and return the session to a state where new commands can
+ be issued. They will also automatically begin a new transaction if executed
+ with a <literal>AND CHAIN</literal> parameter.
+ </para>
+
<para>
It's possible to control the statements in a transaction in a more
granular fashion through the use of <firstterm>savepoints</firstterm>. Savepoints
diff --git a/doc/src/sgml/ref/commit.sgml b/doc/src/sgml/ref/commit.sgml
index 7e2dcac5a3..e4ef573fe5 100644
--- a/doc/src/sgml/ref/commit.sgml
+++ b/doc/src/sgml/ref/commit.sgml
@@ -33,6 +33,19 @@ COMMIT [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]
changes made by the transaction become visible to others
and are guaranteed to be durable if a crash occurs.
</para>
+ <para>
+ If no changes have been made - because the transaction is in an
+ aborted state - the effect of the commit will look like a rollback,
+ including the command tag output.
+ </para>
+ <para>
+ In either situation, if the <literal>AND CHAIN</literal> parameter is
+ specified a new, identically configured, transaction is started.
+ </para>
+ <para>
+ For more information regarding transactions see
+ <xref linkend="tutorial-transactions"/>.
+ </para>
</refsect1>
<refsect1>
@@ -67,6 +80,25 @@ COMMIT [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]
</variablelist>
</refsect1>
+ <refsect1>
+ <title>Outputs</title>
+
+ <para>
+ On successful completion on a non-aborted transaction, a <command>COMMIT</command>
+ command returns a command tag of the form
+<screen>
+COMMIT
+</screen>
+ </para>
+ <para>
+ However, if the transaction being affected is aborted, a <command>COMMIT</command>
+ command returns a command tag of the form
+<screen>
+ROLLBACK
+</screen>
+ </para>
+ </refsect1>
+
<refsect1>
<title>Notes</title>
@@ -107,6 +139,7 @@ COMMIT;
<simplelist type="inline">
<member><xref linkend="sql-begin"/></member>
<member><xref linkend="sql-rollback"/></member>
+ <member><xref linkend="tutorial-transactions"/></member>
</simplelist>
</refsect1>
</refentry>
--
2.34.1
Thoughts?
On Fri, Dec 20, 2024 at 9:02 AM David G. Johnston <
david.g.johnston@gmail.com> wrote:
Show quoted text
Hi,
The commit reference page lacks an "Outputs" section even though it is
capable of outputting both "COMMIT" and "ROLLBACK".The attached adds this section, describes when each applies, and then
incorporates the same into the main description for commit as well as the
transaction section of the tutorial - which presently seems to be the main
discussion area for the topic (the Concurrency Control chapter lacks a
section for this introductory material).This was noted as being needed by Tom Lane back into 2006 but it
never happened.
/messages/by-id/28798.1142608067@sss.pgh.pa.usIt came up again when I was answering a question on Slack regarding
"commit and chain" wondering whether the "and chain" could be made
conditional (i.e., could the new transaction start aborted) on
whether commit outputted "commit" or "rollback".Its left implied that this behavior of "rollback" is standard-conforming.
Please feel free to suggest/add language to the Compatibility section if
this is not the case.David J.
On Tue, Dec 31, 2024 at 12:50 PM David G. Johnston
<david.g.johnston@gmail.com> wrote:
Thoughts?
On Fri, Dec 20, 2024 at 9:02 AM David G. Johnston <david.g.johnston@gmail.com> wrote:
Hi,
The commit reference page lacks an "Outputs" section even though it is capable of outputting both "COMMIT" and "ROLLBACK".
The attached adds this section, describes when each applies, and then incorporates the same into the main description for commit as well as the transaction section of the tutorial - which presently seems to be the main discussion area for the topic (the Concurrency Control chapter lacks a section for this introductory material).
This was noted as being needed by Tom Lane back into 2006 but it never happened.
/messages/by-id/28798.1142608067@sss.pgh.pa.usIt came up again when I was answering a question on Slack regarding "commit and chain" wondering whether the "and chain" could be made conditional (i.e., could the new transaction start aborted) on whether commit outputted "commit" or "rollback".
Its left implied that this behavior of "rollback" is standard-conforming. Please feel free to suggest/add language to the Compatibility section if this is not the case.
I generally agree with the improvements proposed. I currently don't
have the infrastructure to build docs, so the following review is
without the benefit of what the build output looks like.
This line in the patch has a trailing whitespace, which should be removed.
+ <xref linkend="sql-begin"/> and
I believe this sentence can be improved slightly:
+ When a failure does occur during a transaction it is not ended but instead
+ goes into an aborted state.
as: When an error occurs in a transaction block, the transaction goes
into an aborted state.
This borrows the term 'transaction block' introduced in the previous
paragraph (the one before the note), and replaces the word 'failure'
(a very wide category) with 'error' (implying ERRORs raised by SQL
commands inside a transaction block).
I think the following intends to convey that if a transaction block is
in an aborted state due to an error, the COMMIT command will behave
identical to the ROLLBACK command. So the reference to 'changes' is
extraneous, since a transaction block may have encountered error even
without having made any changes.
+ If no changes have been made - because the transaction is in an
+ aborted state - the effect of the commit will look like a rollback,
+ including the command tag output.
So this seems like a better statement: If the transaction is in an
aborted state, say, because of an error, then the effect of the
<command>COMMIT</> will be identical to that of <command>ROLLBACK</>,
including the command tag output.
The following needs to be rephrased:
+ However, if the transaction being affected is aborted, a
<command>COMMIT</command>
+ command returns a command tag of the form
as: However, if the transaction is in an aborted state, the
<command>COMMIT</> command ...
Best regards,
Gurjeet
http://Gurje.et
On Wed, Jan 1, 2025 at 11:16 PM Gurjeet Singh <gurjeet@singh.im> wrote:
On Fri, Dec 20, 2024 at 9:02 AM David G. Johnston <
david.g.johnston@gmail.com> wrote:
The commit reference page lacks an "Outputs" section even though it is
capable of outputting both "COMMIT" and "ROLLBACK".
I generally agree with the improvements proposed. I currently don't
have the infrastructure to build docs, so the following review is
without the benefit of what the build output looks like.
Thank you for the review. Version 2 Attached.
This line in the patch has a trailing whitespace, which should be removed.
+ <xref linkend="sql-begin"/> and
Done
I believe this sentence can be improved slightly:
+ When a failure does occur during a transaction it is not ended but instead + goes into an aborted state.as: When an error occurs in a transaction block, the transaction goes
into an aborted state.
Agreed, and changed the existing usage of failure to error to match.
So this seems like a better statement: If the transaction is in an
aborted state, say, because of an error, then the effect of the
<command>COMMIT</> will be identical to that of <command>ROLLBACK</>,
including the command tag output.
I went with:
+ If the transaction is in an aborted state then no changes will be made
+ and the effect of the <command>COMMIT</command> will be identical to
that
+ of <command>ROLLBACK</command>, including the command tag output.
The following needs to be rephrased:
+ However, if the transaction being affected is aborted, a <command>COMMIT</command> + command returns a command tag of the formas: However, if the transaction is in an aborted state, the
<command>COMMIT</> command ...
I went with this, keeping the phrasing "on an" consistent between this and
the previous text.
+ However, on an aborted transaction, a <command>COMMIT</command>
+ command returns a command tag of the form
The use of "a/an" instead of "the" is supported by existing phrasing for
Insert.
"On successful completion, an INSERT command returns a command tag of the
form"
David J.
Attachments:
v2-0001-doc-Commit-performs-rollback-of-aborted-transactions.patchtext/x-patch; charset=US-ASCII; name=v2-0001-doc-Commit-performs-rollback-of-aborted-transactions.patchDownload
From 2bdcb8d0c5cfffcb4db8c150d568b7a98b82b422 Mon Sep 17 00:00:00 2001
From: "David G. Johnston" <David.G.Johnston@Gmail.com>
Date: Fri, 20 Dec 2024 08:40:47 -0700
Subject: [PATCH] doc: Commit performs rollback of aborted transactions
The Commit command handles an aborted transaction in the same
manner as the Rollback command. This needs to be documented.
Add it to both the reference page as well mentioning the behavior
in the official material for introducting transactions - the tutorial.
In passing, make the description of the Commit reference page
self-contained by mentioning the 'and chain' behavior.
---
doc/src/sgml/advanced.sgml | 18 +++++++++++++++---
doc/src/sgml/ref/commit.sgml | 33 +++++++++++++++++++++++++++++++++
2 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml
index 755c9f1485..6b82e731b9 100644
--- a/doc/src/sgml/advanced.sgml
+++ b/doc/src/sgml/advanced.sgml
@@ -149,7 +149,8 @@ DETAIL: Key (city)=(Berkeley) is not present in table "cities".
systems. The essential point of a transaction is that it bundles
multiple steps into a single, all-or-nothing operation. The intermediate
states between the steps are not visible to other concurrent transactions,
- and if some failure occurs that prevents the transaction from completing,
+ and if <link linkend="tutorial-transactions-aborted">an error</link>
+ occurs that prevents the transaction from completing,
then none of the steps affect the database at all.
</para>
@@ -218,7 +219,8 @@ UPDATE branches SET balance = balance + 100.00
<para>
In <productname>PostgreSQL</productname>, a transaction is set up by surrounding
the SQL commands of the transaction with
- <command>BEGIN</command> and <command>COMMIT</command> commands. So our banking
+ <xref linkend="sql-begin"/> and
+ <xref linkend="sql-commit"/> commands. So our banking
transaction would actually look like:
<programlisting>
@@ -233,7 +235,7 @@ COMMIT;
<para>
If, partway through the transaction, we decide we do not want to
commit (perhaps we just noticed that Alice's balance went negative),
- we can issue the command <command>ROLLBACK</command> instead of
+ we can issue the command <xref linkend="sql-rollback"/> instead of
<command>COMMIT</command>, and all our updates so far will be canceled.
</para>
@@ -256,6 +258,16 @@ COMMIT;
</para>
</note>
+ <para id="tutorial-transactions-aborted">
+ When an error occurs within a transaction block the transaction is not ended
+ but instead goes into an aborted state. While in this state all commands except
+ <xref linkend="sql-commit"/> and <xref linkend="sql-rollback"/> are ignored and,
+ importantly, both those commands behave identically - they roll-back and close
+ the current transaction, returning the session to a state where new commands can
+ be issued. They will also automatically begin a new transaction if executed
+ with a <literal>AND CHAIN</literal> parameter.
+ </para>
+
<para>
It's possible to control the statements in a transaction in a more
granular fashion through the use of <firstterm>savepoints</firstterm>. Savepoints
diff --git a/doc/src/sgml/ref/commit.sgml b/doc/src/sgml/ref/commit.sgml
index 7e2dcac5a3..876a971db6 100644
--- a/doc/src/sgml/ref/commit.sgml
+++ b/doc/src/sgml/ref/commit.sgml
@@ -33,6 +33,19 @@ COMMIT [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]
changes made by the transaction become visible to others
and are guaranteed to be durable if a crash occurs.
</para>
+ <para>
+ If the transaction is in an aborted state then no changes will be made
+ and the effect of the <command>COMMIT</command> will be identical to that
+ of <command>ROLLBACK</command>, including the command tag output.
+ </para>
+ <para>
+ In either situation, if the <literal>AND CHAIN</literal> parameter is
+ specified a new, identically configured, transaction is started.
+ </para>
+ <para>
+ For more information regarding transactions see
+ <xref linkend="tutorial-transactions"/>.
+ </para>
</refsect1>
<refsect1>
@@ -67,6 +80,25 @@ COMMIT [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]
</variablelist>
</refsect1>
+ <refsect1>
+ <title>Outputs</title>
+
+ <para>
+ On successful completion on a non-aborted transaction, a <command>COMMIT</command>
+ command returns a command tag of the form
+<screen>
+COMMIT
+</screen>
+ </para>
+ <para>
+ However, on an aborted transaction, a <command>COMMIT</command>
+ command returns a command tag of the form
+<screen>
+ROLLBACK
+</screen>
+ </para>
+ </refsect1>
+
<refsect1>
<title>Notes</title>
@@ -107,6 +139,7 @@ COMMIT;
<simplelist type="inline">
<member><xref linkend="sql-begin"/></member>
<member><xref linkend="sql-rollback"/></member>
+ <member><xref linkend="tutorial-transactions"/></member>
</simplelist>
</refsect1>
</refentry>
--
2.34.1
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, failed
Spec compliant: tested, failed
Documentation: tested, failed
Summary:
---------
The patch adds documentation to clarify how PostgreSQL handles aborted transactions during the commit process. The changes are clear and improve the existing documentation.
Testing:
--------
1. Manually applied the patch to the latest master branch (commit 4cffc93).
2. Fixed SGML structure issues in `advanced.sgml` and `commit.sgml` by wrapping `<varlistentry>` in `<variablelist>`.
3. Rebuilt the documentation using `make html`.
4. Verified the new sections are present and correctly formatted in the generated HTML.
Feedback:
---------
- The patch was manually applied due to conflicts in `advanced.sgml` and `commit.sgml`.
- Fixed invalid SGML structure by wrapping `<varlistentry>` in `<variablelist>`.
- The documentation is accurate and follows PostgreSQL’s style guidelines.
- No additional issues were found.
Recommendation:
---------------
Ready for committer. No objections.
The new status of this patch is: Ready for Committer
Ahmed,
Thank you for the review.
I'm a bit confused by the reports of apply and compile errors. I didn't
touch anything involving "varlist" and see no errors then or now in my
Meson ninja build. Nor does the CI report any.
On Fri, Feb 14, 2025 at 2:01 PM Ahmed Ashour <a8087027@gmail.com> wrote:
Feedback:
---------
- The patch was manually applied due to conflicts in `advanced.sgml` and
`commit.sgml`.
- Fixed invalid SGML structure by wrapping `<varlistentry>` in
`<variablelist>`.
If those errors were/are real this wouldn't be ready to commit. But as
they seem to be a local environment issue on your end, and you agree with
the content, I'll keep it ready to commit.
David J.
Recent discussion led me to realize we are also contrary to the SQL
Standard here. v3 updates the Commit reference page to reflect this fact.
Leaving ready-to-commit.
David J.
Attachments:
v3-0001-PATCH-doc-Commit-performs-rollback-of-aborted-transa.patchtext/x-patch; charset=US-ASCII; name=v3-0001-PATCH-doc-Commit-performs-rollback-of-aborted-transa.patchDownload
From 9e19152958130f7610feab7983221aace7abfe20 Mon Sep 17 00:00:00 2001
From: "David G. Johnston" <David.G.Johnston@Gmail.com>
Date: Wed, 28 May 2025 16:11:51 -0700
Subject: [PATCH] [PATCH] doc: Commit performs rollback of aborted transactions
The Commit command handles an aborted transaction in the same
manner as the Rollback command. This needs to be documented.
Add it to both the reference page as well mentioning the behavior
in the official material for introducting transactions - the tutorial.
Note the our behavior is contrary to the SQL Standard as well.
In passing, make the description of the Commit reference page
self-contained by mentioning the 'and chain' behavior.
---
doc/src/sgml/advanced.sgml | 18 +++++++++++++---
doc/src/sgml/ref/commit.sgml | 42 ++++++++++++++++++++++++++++++++++--
2 files changed, 55 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml
index e15a3323dfb..db77ca39e73 100644
--- a/doc/src/sgml/advanced.sgml
+++ b/doc/src/sgml/advanced.sgml
@@ -149,7 +149,8 @@ DETAIL: Key (city)=(Berkeley) is not present in table "cities".
systems. The essential point of a transaction is that it bundles
multiple steps into a single, all-or-nothing operation. The intermediate
states between the steps are not visible to other concurrent transactions,
- and if some failure occurs that prevents the transaction from completing,
+ and if <link linkend="tutorial-transactions-aborted">an error</link>
+ occurs that prevents the transaction from completing,
then none of the steps affect the database at all.
</para>
@@ -218,7 +219,8 @@ UPDATE branches SET balance = balance + 100.00
<para>
In <productname>PostgreSQL</productname>, a transaction is set up by surrounding
the SQL commands of the transaction with
- <command>BEGIN</command> and <command>COMMIT</command> commands. So our banking
+ <xref linkend="sql-begin"/> and
+ <xref linkend="sql-commit"/> commands. So our banking
transaction would actually look like:
<programlisting>
@@ -233,7 +235,7 @@ COMMIT;
<para>
If, partway through the transaction, we decide we do not want to
commit (perhaps we just noticed that Alice's balance went negative),
- we can issue the command <command>ROLLBACK</command> instead of
+ we can issue the command <xref linkend="sql-rollback"/> instead of
<command>COMMIT</command>, and all our updates so far will be canceled.
</para>
@@ -256,6 +258,16 @@ COMMIT;
</para>
</note>
+ <para id="tutorial-transactions-aborted">
+ When an error occurs within a transaction block the transaction is not ended
+ but instead goes into an aborted state. While in this state all commands except
+ <xref linkend="sql-commit"/> and <xref linkend="sql-rollback"/> are ignored and,
+ importantly, both those commands behave identically - they roll-back and close
+ the current transaction, returning the session to a state where new commands can
+ be issued. They will also automatically begin a new transaction if executed
+ with an <literal>AND CHAIN</literal> parameter.
+ </para>
+
<para>
It's possible to control the statements in a transaction in a more
granular fashion through the use of <firstterm>savepoints</firstterm>. Savepoints
diff --git a/doc/src/sgml/ref/commit.sgml b/doc/src/sgml/ref/commit.sgml
index 7e2dcac5a33..80c2ecd799e 100644
--- a/doc/src/sgml/ref/commit.sgml
+++ b/doc/src/sgml/ref/commit.sgml
@@ -33,6 +33,19 @@ COMMIT [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]
changes made by the transaction become visible to others
and are guaranteed to be durable if a crash occurs.
</para>
+ <para>
+ If the transaction is in an aborted state then no changes will be made
+ and the effect of the <command>COMMIT</command> will be identical to that
+ of <command>ROLLBACK</command>, including the command tag output.
+ </para>
+ <para>
+ In either situation, if the <literal>AND CHAIN</literal> parameter is
+ specified a new, identically configured, transaction is started.
+ </para>
+ <para>
+ For more information regarding transactions see
+ <xref linkend="tutorial-transactions"/>.
+ </para>
</refsect1>
<refsect1>
@@ -67,6 +80,25 @@ COMMIT [ WORK | TRANSACTION ] [ AND [ NO ] CHAIN ]
</variablelist>
</refsect1>
+ <refsect1>
+ <title>Outputs</title>
+
+ <para>
+ On successful completion on a non-aborted transaction, a <command>COMMIT</command>
+ command returns a command tag of the form
+<screen>
+COMMIT
+</screen>
+ </para>
+ <para>
+ However, on an aborted transaction, a <command>COMMIT</command>
+ command returns a command tag of the form
+<screen>
+ROLLBACK
+</screen>
+ </para>
+ </refsect1>
+
<refsect1>
<title>Notes</title>
@@ -96,8 +128,13 @@ COMMIT;
<title>Compatibility</title>
<para>
- The command <command>COMMIT</command> conforms to the SQL standard. The
- form <literal>COMMIT TRANSACTION</literal> is a PostgreSQL extension.
+ The command <command>COMMIT</command> conforms to the SQL standard, except
+ that no exception condition is raised in the case where an already aborted
+ transaction is committed.
+ </para>
+
+ <para>
+ The form <literal>COMMIT TRANSACTION</literal> is a PostgreSQL extension.
</para>
</refsect1>
@@ -107,6 +144,7 @@ COMMIT;
<simplelist type="inline">
<member><xref linkend="sql-begin"/></member>
<member><xref linkend="sql-rollback"/></member>
+ <member><xref linkend="tutorial-transactions"/></member>
</simplelist>
</refsect1>
</refentry>
--
2.34.1
On Thu, 29 May 2025 at 04:32, David G. Johnston
<david.g.johnston@gmail.com> wrote:
Recent discussion led me to realize we are also contrary to the SQL Standard here. v3 updates the Commit reference page to reflect this fact.
Leaving ready-to-commit.
David J.
Hi!
I reviewed your changes and I agree with them.
The only aspect that drew my attention is in the following sentence:
+ but instead goes into an aborted state. While in this state all commands except + <xref linkend="sql-commit"/> and <xref linkend="sql-rollback"/> are ignored
We can also do ABORT;
Is this worth noting?
--
Best regards,
Kirill Reshke
On Friday, August 22, 2025, Kirill Reshke <reshkekirill@gmail.com> wrote:
We can also do ABORT;
Listing commands described as being “present for historical reasons” in the
documentation seems unnecessary. We don’t list abort in the “See Also”
section either.
David J.