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

From Julien Rouhaud
Subject Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?
Date
Msg-id CAOBaU_ZbHCmZju5fp7T30FPtp85-MN6MCWypM82-bMoL2ZZ8Cw@mail.gmail.com
Whole thread Raw
In response to Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?  (Michael Paquier <michael@paquier.xyz>)
Responses Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?
List pgsql-hackers
On Tue, Sep 7, 2021 at 12:20 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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?

That's also my understanding, so +1 to apply that soon

> 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.

+1



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Estimating HugePages Requirements?
Next
From: Amit Kapila
Date:
Subject: Re: Column Filtering in Logical Replication