On 8/21/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Marko Kreen" <markokr@gmail.com> writes:
> > On 8/21/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> I'm not following the point here. Dump and restore has never intended
> >> to preserve the transaction counter, so why should it preserve
> >> high-order bits of the transaction counter?
>
> > Thus it guarantees that any new issued large txid's will be larger
> > than existing ones in tables. Thus code can depend on monotonous
> > growth.
>
> Within a single installation, sure, but I don't buy that we ought to try
> to preserve XIDs across installations.
I think you are right in the respect that we should not do it
automatically.
But now that the long xids may end up in data tables, user may have the
need dump/restore it in another installation. If the application
is eg. Slony like queue, that depends on xid growth, user needs to
be able to bump epoch or application level support for migration.
If he has neither, he needs basically to extract old contents by hand
(as app would not work reliably) and reset everything.
Probably the right thing would be for application have a functions
"we moved, fix everything". But bumping epoch is such a simple
way of fixing it that it should still be available.
And pg_resetxlog is fine for that. Espacially as using it signals
"It's dangerous what you are doing!"
--
marko
