From: | "Finnerty, Jim" <jfinnert(at)amazon(dot)com> |
---|---|
To: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Cc: | Maxim Orlov <orlovmg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Add 64-bit XIDs into PostgreSQL 15 |
Date: | 2022-01-07 15:53:51 |
Message-ID: | 9AFAF000-2E9E-443E-9EC3-7B67D6A03E5B@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Re: The "prepare" approach was the first tried.
https://github.com/postgrespro/pg_pageprep
But it appears to be very difficult and unreliable. After investing
many months into pg_pageprep, "double xmax" approach appears to be
very fast to implement and reliable.
I'd still like a plan to retire the "double xmax" representation eventually. Previously I suggested that this could be done 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 subsequent major version upgrades (e.g. to PG16, if "double xmax" pages are introduced in PG15). This gives the luxury of time after a fast upgrade to convert all pages to contain the epochs, while still providing a path to more maintainable code in the future.
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2022-01-07 16:09:21 | Re: Add 64-bit XIDs into PostgreSQL 15 |
Previous Message | Fujii Masao | 2022-01-07 15:49:10 | Re: enhance pg_log_backend_memory_contexts() to log memory contexts of auxiliary processes |