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

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> No, pg_upgrade should not be unilaterally refusing that.
>
> > 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.
>
> This argument seems a tad peculiar, since the *entire* *point* of
> pg_upgrade is to push physical files from one installation into another
> even though compatibility isn't guaranteed. It is the program's duty to
> understand enough to know whether it can transport the cluster's state
> safely. Not to arbitrarily discard state because it might possibly not
> be transportable.

Well, pg_upgrade succeeds because it does as little as necessary to do
the migration, relying on pg_dump to do much of the migration work at
the catalog level. pg_upgrade tries to be involved as little as
possible with the Postgres code so it doesn't have to be changed
regularly between major versions.

The prepared transaction case seems ugly enough that we don't want
pg_upgrade to have to check every major release if anything changed
about the data stored in prepared transactions. This is the same reason
pg_upgrade doesn't transfer WAL files from the old cluster, just pg_clog
files (which rarely changes its format).

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +