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. +
