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