Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Actually, 8.2 initializes it to InvalidTransactionId too, so it doesn't
> seem like there's a problem there either. Since the problem stems from
> using it as initializer for the Min() calculation, there's no actual bug
> on 8.2 either. The bug only appeared on 8.3 when the initializer was
> changed. And given that there's no HOT in 8.2, then there's no danger
> of misusing it in page pruning either.
I concur that 8.2 has no problem except in vac_update_datfrozenxid,
but I think it is an actual bug there. If newFrozenXid starts out as
InvalidTransactionId, it'll stay that way because InvalidTransactionId
sorts as older than anything else. The result will be that the routine
fails to advance datfrozenxid, which leads to exactly the type of
autovacuum misbehavior that I saw in HEAD. (Actually there's another
problem in an assert-enabled build: it'll fail at the
Assert(TransactionIdIsNormal(newFrozenXid)) ...)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
