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
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 |
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 |