From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org, Pawel Kudzia <kudzia(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows |
Date: | 2021-07-23 21:47:33 |
Message-ID: | 103FFD68-8585-4556-8C0E-CA37AAEE9273@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 23 July 2021 18:04:50 EEST, Pawel Kudzia <kudzia(at)gmail(dot)com> wrote:
>On Fri, Jul 23, 2021 at 3:46 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>>
>> Ok, so the index is missing entries for the correct key. Looks like the
>> index entries were inserted into the wrong subtree, under wrong key. But
>> *how* did that happen? I'm out of ideas, I'm afraid :-(.
Can you tell more about the workload? What INSERT/UPDATE/DELETE commands do you run? How many concurrent clients? Do you run vacuum manually or how often does autovacuum kick in? How long did it take for the problem to appear? What queries did you run to find the corruption, and how often?
I know it's a big ask, but would it be possible to simplify the test case further, to make it reproduce faster? Ideally as a self-contained test script with any sensitive data removed.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2021-07-23 22:30:21 | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
Previous Message | Andrey Borodin | 2021-07-23 16:33:18 | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |