Re: Interesting glitch in autovacuum

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interesting glitch in autovacuum
Date: 2008-09-11 12:09:54
Message-ID: 17049.1221134994@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2008-09-11 12:10:23 Re: Transaction Snapshots and Hot Standby
Previous Message Peter Eisentraut 2008-09-11 12:02:25 Re: Move src/tools/backend/ to wiki