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:
[skipped] > > 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 > having the server in an intermediate state while running queries is very > complex --- it might be simpler to just accept two XID formats all the > time than enabling the server to run with two formats for a short > period. My big point is that this needs more thought. Probably, some table storage housekeeping would be wanted. Like a column in pg_class describing the current set of options of the table: checksums added, 64-bit xids added, type of 64-bit xids (probably some would want to add support for the pgpro up- grades), some set of defaults to not include a lot of them in all pageheaders -- like compressed xid/integer formats or extended pagesize. And separate tables that describe the transition state -- like when adding checksums, the desired state for the relation (checksums), and a set of ranges in the table files that are al- ready transitioned/checked. That probably will not introduce too much slowdown at least on reading, and will add the transition/upgrade mechanics. Aren't there were already some discussions about such a feature in the mailing lists? > > > -- > Bruce Momjian <br...@momjian.us> https://momjian.us > EDB https://enterprisedb.com > > If only the physical world exists, free will is an illusion. > >