Re: BUG #5599: Vacuum fails due to index corruption issues

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hitesh Bhambhani <hitesh(dot)bhambhani(at)asg(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5599: Vacuum fails due to index corruption issues
Date: 2010-08-06 02:44:30
Message-ID: AANLkTikwnU3g=G9gwZ7r_Vkg4R3hrdL9Eie0+18ZK-Wk@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Thu, Aug 5, 2010 at 7:28 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
>
> The scope is further reduced by the fact that this only seems to happen
> on Windows, and then only when the antivirus is messing around with the
> files.

So I suspect this could be triggered lots of ways. Imagine a ZFS
volume that runs out of space temporarily. Even truncate would need
additional blocks to replace the meta information. Or a network
filesystem like AFS where your kerberos tickets have expired and you
get a permission failure until they've been renewed. Or, in the case
of a very large table being truncated I suspect there's a
CHECK_FOR_INTERRUPTS lying around that can cancel the backend at the
wrong time.

It would be nice to have a regression test harness that caused system
calls to fail randomly -- the difficult part would be testing the
results.

--
greg

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2010-08-06 03:20:11 Re: Re: BUG #5602: Recovering from Hot-Standby file backup leads to the currupted indexes
Previous Message Simon Riggs 2010-08-05 22:50:21 Re: Re: BUG #5602: Recovering from Hot-Standby file backup leads to the currupted indexes

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2010-08-06 03:11:04 Re: Initial review of xslt with no limits patch
Previous Message Alvaro Herrera 2010-08-06 02:29:10 Re: [PATCH] Re: Adding xpath_exists function