Re: Interesting glitch in autovacuum - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Interesting glitch in autovacuum
Date
Msg-id 17049.1221134994@sss.pgh.pa.us
Whole thread Raw
In response to Re: Interesting glitch in autovacuum  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> 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


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: New FSM patch
Next
From: "Merlin Moncure"
Date:
Subject: Re: Transaction Snapshots and Hot Standby