Re: SSI patch renumbered existing 2PC resource managers??
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>, drkp@csail.mit.edu, pgsql-hackers@postgreSQL.org
Date: 2011-06-14T09:40:32Z
Lists: pgsql-hackers
On 13.06.2011 22:33, Tom Lane wrote: > Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes: >> On 13.06.2011 21:31, Tom Lane wrote: >>> So far as I can tell, that breaks pg_upgrade (if there are any open >>> prepared transactions) for no redeeming social benefit. > >> Surely pg_upgrade can't work anyway if there's any open prepared >> transactions in the database. We're not going to guarantee to keep all >> the data structures we write in two-phase state files unchanged over >> major releases. If pg_upgrade is not checking for prepared transcations >> at the moment, such a check should probably should be added. > > No, pg_upgrade should not be unilaterally refusing that. The correct > way to deal with this consideration is to change the TWOPHASE_MAGIC > number when we make a change in on-disk 2PC state. Which wasn't done > in the SSI patch. We can either change that now, or undo the > unnecessary change in existing RM IDs. I vote for the latter. Ok, I've renumbered the existing RMs back the way they were. I nevertheless don't think it's worthwhile to try to migrate 2pc state files in pg_upgrade. More than likely, it's a mistake on part of the admin anyway if there is a prepared transaction open at that point. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com