Re: SSI patch renumbered existing 2PC resource managers??
От | Heikki Linnakangas |
---|---|
Тема | Re: SSI patch renumbered existing 2PC resource managers?? |
Дата | |
Msg-id | 4DF72C90.8000608@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: SSI patch renumbered existing 2PC resource managers?? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: