Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows |
| Дата | |
| Msg-id | 103FFD68-8585-4556-8C0E-CA37AAEE9273@iki.fi обсуждение исходный текст |
| Ответ на | Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows (Pawel Kudzia <kudzia@gmail.com>) |
| Ответы |
Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
|
| Список | pgsql-bugs |
On 23 July 2021 18:04:50 EEST, Pawel Kudzia <kudzia@gmail.com> wrote: >On Fri, Jul 23, 2021 at 3:46 PM Heikki Linnakangas <hlinnaka@iki.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 yourun vacuum manually or how often does autovacuum kick in? How long did it take for the problem to appear? What queriesdid 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 asa self-contained test script with any sensitive data removed. - Heikki
В списке pgsql-bugs по дате отправления: