Re: Interesting glitch in autovacuum

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

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.
This is OK except in VACUUM where we anyways use OldestXmin. So I
don't see a real problem here. But its good to fix the larger problem
as per the suggestion.

Thanks,
Pavan

--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2008-09-11 05:53:33 Commitfest patches mostly assigned ... status
Previous Message Alex Hunsaker 2008-09-11 04:17:31 Re: hash index improving v3