On Wed, Jan 5, 2022 at 06:12:26PM -0600, Justin Pryzby wrote: > On Wed, Jan 05, 2022 at 06:51:37PM -0500, Bruce Momjian wrote: > > On Tue, Jan 4, 2022 at 10:22:50PM +0000, Finnerty, Jim wrote: > > > I'm concerned about the maintainability impact of having 2 new > > > on-disk page formats. It's already complex enough with XIDs and > > > multixact-XIDs. > > > > > > If the lack of space for the two epochs in the special data area is > > > a problem only in an upgrade scenario, why not resolve the problem > > > before completing the upgrade process like a kind of post-process > > > pg_repack operation that converts all "double xmax" pages to > > > the "double-epoch" page format? i.e. maybe the "double xmax" > > > representation is needed as an intermediate representation during > > > upgrade, but after upgrade completes successfully there are no pages > > > with the "double-xmax" representation. This would eliminate a whole > > > class of coding errors and would make the code dealing with 64-bit > > > XIDs simpler and more maintainable. > > > > Well, yes, we could do this, and it would avoid the complexity of having > > to support two XID representations, but we would need to accept that > > fast pg_upgrade would be impossible in such cases, since every page > > would need to be checked and potentially updated. > > > > You might try to do this while the server is first started and running > > queries, but I think we found out from the online checkpoint patch that > > I think you meant the online checksum patch. Which this reminded me of, too. > > https://commitfest.postgresql.org/31/2611/
Sorry, yes, I have checkpoint on my mind. ;-) -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
