Re: Interesting glitch in autovacuum
От | Tom Lane |
---|---|
Тема | Re: Interesting glitch in autovacuum |
Дата | |
Msg-id | 17049.1221134994@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Interesting glitch in autovacuum (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | 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 по дате отправления: