Excerpts from Heikki Linnakangas's message of mar ene 17 03:21:28 -0300 2012: > > On 16.01.2012 21:52, Alvaro Herrera wrote: > > > > Excerpts from Heikki Linnakangas's message of lun ene 16 16:17:42 -0300 > > 2012: > >> > >> On 15.01.2012 06:49, Alvaro Herrera wrote: > >>> - pg_upgrade bits are missing. > >> > >> I guess we'll need to rewrite pg_multixact contents in pg_upgrade. Is > >> the page format backwards-compatible? > > > > It's not. > > > > I haven't worked out what pg_upgrade needs to do, honestly. I think we > > should just not copy old pg_multixact files when upgrading across this > > patch. > > Sorry, I meant whether the *data* page format is backwards-compatible? > the multixact page format clearly isn't.
It's supposed to be, yes. The HEAP_XMAX_IS_NOT_UPDATE bit (now renamed) was chosen so that it'd take the place of the old HEAP_XMAX_SHARE_LOCK bit, so any pages with that bit set should continue to work similarly. The other infomask bits I used were previously unused. > > I was initially thinking that pg_multixact should return the > > empty set if requested members of a multi that preceded the freeze > > point. That way, I thought, we would just never try to access a page > > originated in the older version (assuming the freeze point is set to > > "current" whenever pg_upgrade runs). However, as things currently > > stand, accessing an old multi raises an error. So maybe we need a > > scheme a bit more complex to handle this. > > Hmm, could we create new multixact files filled with zeros, covering the > range that was valid in the old cluster? Hm, we could do something like that I guess. I'm not sure that just zeroes is the right pattern, but it should be something simple. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers