On 8/21/06, Tom Lane <[EMAIL PROTECTED]> wrote:
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> On 8/21/06, Tom Lane <[EMAIL PROTECTED]> 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
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
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!"
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not