Re: SSI patch renumbered existing 2PC resource managers??

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.

Uh, isn't there some physical files in pg_twophase/ that stick around to
keep prepared transactions --- if so, pg_upgrade does not copy them from
the old cluster to the new one.  I am also hesistant to do so because
there might be data in there that isn't portable.  I like the idea of
adding a check, I assume by reading pg_prepared_xact().

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +