Re: Add 64-bit XIDs into PostgreSQL 15

Поиск
Список
Период
Сортировка
От Justin Pryzby
Тема Re: Add 64-bit XIDs into PostgreSQL 15
Дата
Msg-id 20220107160921.GD14051@telsasoft.com
обсуждение исходный текст
Ответ на Re: Add 64-bit XIDs into PostgreSQL 15  ("Finnerty, Jim" <jfinnert@amazon.com>)
Ответы Re: Add 64-bit XIDs into PostgreSQL 15  (Simon Riggs <simon.riggs@enterprisedb.com>)
Список pgsql-hackers
On Fri, Jan 07, 2022 at 03:53:51PM +0000, Finnerty, Jim wrote:
> I'd still like a plan to retire the "double xmax" representation eventually.  Previously I suggested that this could
bedone as a post-process, before upgrade is complete, but that could potentially make upgrade very slow. 
 
> 
> Another way to retire the "double xmax" representation eventually could be to disallow "double xmax" pages in
subsequentmajor version upgrades (e.g. to PG16, if "double xmax" pages are introduced in PG15).  This gives the luxury
oftime after a fast upgrade to convert all pages to contain the epochs, while still providing a path to more
maintainablecode in the future.
 

Yes, but how are you planning to rewrite it?  Is vacuum enough?
I suppose it'd need FREEZE + DISABLE_PAGE_SKIPPING ?

This would preclude upgrading "across" v15.  Maybe that'd be okay, but it'd be
a new and atypical restriction.

How would you enforce that it'd been run on v15 before upgrading to pg16 ?

You'd need to track whether vacuum had completed the necessary steps in pg15.
I don't think it'd be okay to make pg_upgrade --check to read every tuple.

The "keeping track" part is what reminds me of the online checksum patch.
It'd be ideal if there were a generic solution to this kind of task, or at
least a "model" process to follow.

-- 
Justin



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

Предыдущее
От: "Finnerty, Jim"
Дата:
Сообщение: Re: Add 64-bit XIDs into PostgreSQL 15
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Add 64-bit XIDs into PostgreSQL 15