From: Bruce Momjian <bruce@momjian.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Robert Treat <rob@xzilla.net>
Cc: Simon Riggs <simon.riggs@enterprisedb.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Erik Rijkers <er@xs4all.nl>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: New docs chapter on Transaction Management and related changes
Date: Fri, 18 Nov 2022 14:31:38 -0500
Message-ID: <Y3fdmraihcI2uIFs@momjian.us> (raw)
In-Reply-To: <e49d9e5fe0e30a9f44cf364b436e84c5d063c3b6.camel@cybertec.at>
References: <20221014084615.chvollxv3oz43oqu@alvherre.pgsql>
<CANbhV-E287+hqhEbC7vCShT16LKYM8aUhrvxQZdjX2osKAETkQ@mail.gmail.com>
<Y0m9tIrlMqaA9dwP@momjian.us>
<CAJSLCQ32vZ8S+yFbO1bKbKT=JE8Q6oRJXeRqfN6Atk-XJKPr7g@mail.gmail.com>
<Y0tZf7N+cUJ9ebPI@momjian.us>
<80a5fd9c080d66e62f90c9565e3e1b54e61f584c.camel@cybertec.at>
<CANbhV-GafnnLmyMmjwYGFFcspk_twoEO56M3jiB7D0p_TkUmZA@mail.gmail.com>
<3603e6e85544daa5300c7106c31bc52673711cd0.camel@cybertec.at>
<CAJSLCQ0fH4Jt0yiJVbXmCmJUYP4h4fXzoyiUU6Nxva4KWGZG6A@mail.gmail.com>
<e49d9e5fe0e30a9f44cf364b436e84c5d063c3b6.camel@cybertec.at>
On Thu, Nov 10, 2022 at 08:39:29AM +0100, Laurenz Albe wrote:
> > > I don't think that is an improvement. "Unaborted" is an un-word. A new transaction
> > > is always "unaborted", isn't it?
> >
> > I thought about this as well when reviewing it, but I do think
> > something is needed for the case where you have a transaction which
> > has suffered an error and then you issue "rollback and chain"; if you
> > just say "a new transaction is immediately started with the same
> > transaction characteristics" it might imply to some the new
> > transaction has some kind of carry over of the previous broken
> > transaction... the use of the word unaborted makes it clear that the
> > new transaction is 100% functional.
>
> A new transaction is never aborted in my understanding. Being aborted is not a
> characteristic of a transaction, but a state.
I used "(unaborted)", which seems to be a compromise.
> > > > + The internal transaction ID type <type>xid</type> is 32-bits wide
> > >
> > > There should be no hyphen in "32 bits wide", just as in "3 years old".
> >
> > Minor aside, we should clean up glossary.sgml as well.
>
> Right, it has this:
>
> The numerical, unique, sequentially-assigned identifier that each
> transaction receives when it first causes a database modification.
> Frequently abbreviated as <firstterm>xid</firstterm>.
> When stored on disk, xids are only 32-bits wide, so only
> approximately four billion write transaction IDs can be generated;
> to permit the system to run for longer than that,
> <firstterm>epochs</firstterm> are used, also 32 bits wide.
>
> Which reminds me that I should have suggested <firstterm> rather than
> <quote> where I complained about the use of <literal>.
I changed them to "firstterm".
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bruce@momjian.us, laurenz.albe@cybertec.at, rob@xzilla.net, simon.riggs@enterprisedb.com, alvherre@alvh.no-ip.org, er@xs4all.nl, pryzby@telsasoft.com
Subject: Re: New docs chapter on Transaction Management and related changes
In-Reply-To: <Y3fdmraihcI2uIFs@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox