|From:||Michael Paquier <michael(at)paquier(dot)xyz>|
|To:||David Steele <david(at)pgmasters(dot)net>|
|Cc:||"Finnerty, Jim" <jfinnert(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>|
|Subject:||Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|Next Message||Amit Kapila||2021-09-07 05:00:18||Re: Column Filtering in Logical Replication|
|Previous Message||Shinoda, Noriyoshi (PN Japan FSIP)||2021-09-07 04:09:01||RE: Improve logging when using Huge Pages|