Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1ow75Y-0000Lc-1L
	for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Nov 2022 19:31:48 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1ow75W-0006Xn-RQ
	for pgsql-hackers@arkaria.postgresql.org; Fri, 18 Nov 2022 19:31:46 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <bruce@momjian.us>)
	id 1ow75W-0006Xd-Hr
	for pgsql-hackers@lists.postgresql.org; Fri, 18 Nov 2022 19:31:46 +0000
Received: from momjian.us ([72.94.173.45])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <bruce@momjian.us>)
	id 1ow75U-0005LV-3R
	for pgsql-hackers@postgresql.org; Fri, 18 Nov 2022 19:31:45 +0000
Received: from bruce by momjian.us with local (Exim 4.94.2)
	(envelope-from <bruce@momjian.us>)
	id 1ow75O-006OgP-TJ; Fri, 18 Nov 2022 14:31:38 -0500
Date: Fri, 18 Nov 2022 14:31:38 -0500
From: Bruce Momjian <bruce@momjian.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Robert Treat <rob@xzilla.net>,
	Simon Riggs <simon.riggs@enterprisedb.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Erik Rijkers <er@xs4all.nl>, Justin Pryzby <pryzby@telsasoft.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: New docs chapter on Transaction Management and related changes
Message-ID: <Y3fdmraihcI2uIFs@momjian.us>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <e49d9e5fe0e30a9f44cf364b436e84c5d063c3b6.camel@cybertec.at>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/Y3fdmraihcI2uIFs%40momjian.us>
Precedence: bulk

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