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

From Heikki Linnakangas
Subject Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
Date
Msg-id e31fc916-1aee-18bc-ba9a-c612b3cf4f82@iki.fi
Whole thread Raw
In response to Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows  (Pawel Kudzia <kudzia@gmail.com>)
Responses Re: IRe: BUG #16792: silent corruption of GIN index resulting in SELECTs returning non-matching rows
List pgsql-bugs
On 14/07/2021 17:37, Pawel Kudzia wrote:
> Heikki - the data is semi-sensitive. I cannot share the whole table.
> I could if it was possible to remove some columns or isolate only
> handful of rows.
> 
> But - just doing the "vacuum full entity" resolves the original issue
> and select returns 0 rows, as it should.

Ok. One idea would be to write a program or extension that overwrites 
all the uninteresting columns with zeros.

> How can I identify relevant pages to make selective dump of them for
> you, using method proposed by Peter?

It's a bit hard without knowing which index pages are affected. But the 
attached script (dump-gin-page-info.sql) dumps some summary information 
about the kind of pages there are. That's a start.

> Would interactive session where you can get temporary access to the
> server with copy of the database,
> to run gdb on it be of any help?

Let's try one thing first: I rebased a patch to add GIN support to the 
amcheck extension [1]. I kind of doubt that it will catch the corruption 
in this case, but you never know. So please apply the attached 
v2-0001-Amcheck-for-GIN-13stable.patch patch. It is the same patch I 
posted at [1], but the installation script is slightly different to make 
it work on PostgreSQL v13. Then compile install it:

   cd contrib/amcheck; make install

Then in psql:

   CREATE EXTENSION amcheck;
   gin_index_parent_check('entity_attribute_name_ids_gin');

If it reports any inconsistencies, we can try to use pageinspect to 
gather further evidence on them.

[1] 
https://www.postgresql.org/message-id/a5bc2aad-464b-91bd-061d-28af0f9b634c%40iki.fi
- Heikki

Attachment

pgsql-bugs by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: BUG #17103: WAL segments are not removed after exceeding max_slot_wal_keep_size
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: BUG #17103: WAL segments are not removed after exceeding max_slot_wal_keep_size