Date: Wed, 5 Jan 2022 18:12:26 -0600
From: Justin Pryzby <pryzby@telsasoft.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: "Finnerty, Jim" <jfinnert@amazon.com>,
	Stephen Frost <sfrost@snowman.net>, Maxim Orlov <orlovmg@gmail.com>,
	pgsql-hackers@postgresql.org
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Message-ID: <20220106001226.GS14051@telsasoft.com>
References: 
 <CACG=ezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe=pyyjVWA@mail.gmail.com>
 <20220104193220.GL15820@tamriel.snowman.net>
 <CB919F14-2B98-4CD3-84C0-91945E9E7EF5@amazon.com>
 <YdYvCT3LmItnTTwz@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YdYvCT3LmItnTTwz@momjian.us>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20220106001226.GS14051%40telsasoft.com>
Precedence: bulk

On Wed, Jan 05, 2022 at 06:51:37PM -0500, Bruce Momjian wrote:
> On Tue, Jan 4, 2022 at 10:22:50PM +0000, Finnerty, Jim wrote:
> > I'm concerned about the maintainability impact of having 2 new
> > on-disk page formats.  It's already complex enough with XIDs and
> > multixact-XIDs.
> >
> > If the lack of space for the two epochs in the special data area is
> > a problem only in an upgrade scenario, why not resolve the problem
> > before completing the upgrade process like a kind of post-process
> > pg_repack operation that converts all "double xmax" pages to
> > the "double-epoch" page format? i.e. maybe the "double xmax"
> > representation is needed as an intermediate representation during
> > upgrade, but after upgrade completes successfully there are no pages
> > with the "double-xmax" representation.  This would eliminate a whole
> > class of coding errors and would make the code dealing with 64-bit
> > XIDs simpler and more maintainable.
> 
> Well, yes, we could do this, and it would avoid the complexity of having
> to support two XID representations, but we would need to accept that
> fast pg_upgrade would be impossible in such cases, since every page
> would need to be checked and potentially updated.
> 
> You might try to do this while the server is first started and running
> queries, but I think we found out from the online checkpoint patch that

I think you meant the online checksum patch.  Which this reminded me of, too.

https://commitfest.postgresql.org/31/2611/

> having the server in an intermediate state while running queries is very
> complex --- it might be simpler to just accept two XID formats all the
> time than enabling the server to run with two formats for a short
> period.  My big point is that this needs more thought.

-- 
Justin