Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?
Date
Msg-id YTboaf4al4nxsghR@paquier.xyz
Whole thread Raw
In response to Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?  (David Steele <david@pgmasters.net>)
Responses Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?
List pgsql-hackers
On Fri, Mar 26, 2021 at 09:54:21AM -0400, David Steele wrote:
> I'm going to move this to the 2021-07 CF and leave it in the Waiting for
> Author state. It would probably be best to wait until just before the CF to
> rebase since anything you do now will likely be broken by the flurry of
> commits that will happen in the next two weeks before feature freeze.

And a couple of months later, the development cycle of 15 has begun.
While re-reading the thread, I got the impression that there is no
reason to not move on with at least the 64-bit GUC part, and that it
could be useful as a piece to move forward with the rest.  Am I
getting the wrong impression?

0001 still applies and compiles, but we don't test this API set at
all.  This could be done by moving one of the existing GUCs to this
new category, but the same can also be achieved with
DefineCustomInt64Variable().  One simple idea would be to change
one of the GUCs of worker_spi to int64, like worker_spi.naptime with
some of the hooks set for coverage, in combination with some new SHOW
commands in the existing regression tests.

Thoughts?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: "Shinoda, Noriyoshi (PN Japan FSIP)"
Date:
Subject: RE: Improve logging when using Huge Pages
Next
From: Amit Kapila
Date:
Subject: Re: Column Filtering in Logical Replication