Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?
Дата
Msg-id YTboaf4al4nxsghR@paquier.xyz
обсуждение исходный текст
Ответ на Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?  (David Steele <david@pgmasters.net>)
Ответы Re: [UNVERIFIED SENDER] Re: Challenges preventing us moving to 64 bit transaction id (XID)?  (Julien Rouhaud <rjuju123@gmail.com>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Shinoda, Noriyoshi (PN Japan FSIP)"
Дата:
Сообщение: RE: Improve logging when using Huge Pages
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Column Filtering in Logical Replication