Date: Wed, 5 Jan 2022 19:03:55 -0500
From: Bruce Momjian <bruce@momjian.us>
To: "Finnerty, Jim" <jfinnert@amazon.com>
Cc: Maxim Orlov <orlovmg@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Add 64-bit XIDs into PostgreSQL 15
Message-ID: <YdYx6+IrS0PtWIpr@momjian.us>
References: 
 <CACG=ezZe1NQSCnfHOr78AtAZxJZeCvxrts0ygrxYwe=pyyjVWA@mail.gmail.com>
 <90BAF0BF-69DF-45C4-821C-76A487210682@amazon.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <90BAF0BF-69DF-45C4-821C-76A487210682@amazon.com>
Archived-At: 
 <https://www.postgresql.org/message-id/YdYx6%2BIrS0PtWIpr%40momjian.us>
Precedence: bulk

On Tue, Jan  4, 2022 at 05:49:07PM +0000, Finnerty, Jim wrote:
> Hi Maxim,
>     I’m glad to see that you’re trying to carry the 64-bit XID work forward.  I
> had not noticed that my earlier patch (also derived from Alexander Kortkov’s
> patch) was responded to back in September.  Perhaps we can merge some of the
> code cleanup that it contained, such as using XID_FMT everywhere and creating a
> type for the kind of page returned by TransactionIdToPage() to make the code
> cleaner.
> 
>     Is your patch functionally the same as the PostgresPro implementation?  If
> so, I think it would be helpful for everyone’s understanding to read the
> PostgresPro documentation on VACUUM.  See in particular section “Forced
> shrinking pg_clog and pg_multixact”
>
>     https://postgrespro.com/docs/enterprise/9.6/routine-vacuuming#
> vacuum-for-wraparound

Good point --- we still need vacuum freeze.  It would be good to
understand how much value we get in allowing vacuum freeze to be done
less often --- how big can pg_xact/pg_multixact get before they are
problems?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.