Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows

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

In response to

Responses

Browse pgsql-bugs by date

  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