Re: Index Corruption

From: Andy Colson <andy(at)squeakycode(dot)net>
To: Dylan Adams <dylan(dot)adams(dot)work(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: Index Corruption
Date: 2011-09-12 18:20:36
Message-ID: 4E6E4D74.3030901@squeakycode.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 9/12/2011 1:10 PM, Dylan Adams wrote:
> On Mon, Sep 12, 2011 at 9:41 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Dylan Adams<dylan(dot)adams(dot)work(at)gmail(dot)com> writes:
>>> [ persistent occurrences of index corruption ]
>>
>>> My primary question: is this normal?
>>
>> No. It does sound like you're managing to tickle some bug or other.
>> Can you extract a test case of any kind? We could fix it if we could
>> see it happening, but there's not enough information here for that.
>
> I haven't been able to come up with a self contained test case.
>
> There have been a few instances where a particular series of batch
> processes which, when run repeatedly on a particular data set, will
> reproduce the problem consistently. But it's not possible to release
> the required code and data.
>
> dylan
>

How about some specifics about the process? Maybe I can work up a
look-a-like.

Something like:

we have two clients that insert as fast as possible into this temp table:

create table....;

we have 5 clients select/insert/delete from temp into live table that
looks like :

create table....;

I'll post my scripts and you can yea/nea them until we get close, maybe
find the problem along the way.

I would not need data or code, but actual table structure's sure would
be swell.

-Andy

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2011-09-12 19:28:48 Re: Problem with the 9.1 one-click installer Windows7 64bit
Previous Message Dylan Adams 2011-09-12 18:12:09 Re: Index Corruption