Re: Interesting glitch in autovacuum

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interesting glitch in autovacuum
Date: 2008-09-11 11:14:56
Message-ID: 15626.1221131696@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com> writes:
> On Wed, Sep 10, 2008 at 9:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> On reflection I'm not even sure that this is strictly an autovacuum
>> bug. It can be cast more generically as "RecentGlobalXmin getting
>> used without ever having been set", and it sure looks to me like the
>> HOT patch may have introduced a few risks of that sort.

> ISTM that HOT may be safe here because even if RecentGlobalXmin is not
> set and has the boot time value of FirstNormalTransactionId, the
> heap_page_prune_opt() would just return without doing any real work.

Until the XID counter advances past the 2billion mark. Then the
uninitialized RecentGlobalXmin would be "in the future" and would
result in mistaken decisions *to* prune, not to not prune.

In short this is a risk-of-data-loss bug. Once the patch is in
I think we ought to start thinking about a set of update releases...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-09-11 11:18:18 Re: Transaction Snapshots and Hot Standby
Previous Message Gregory Stark 2008-09-11 11:12:01 Re: Postgresql coding conventions