Re: Duplicate Item Pointers in Gin index

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: "R, Siva" <sivasubr(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Duplicate Item Pointers in Gin index
Date: 2018-06-13 06:32:43
Message-ID: CAH2-Wz=oNBzjfV82vSAdvFMf35UPY9bTMMqWZG4erpevC83hqg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jun 12, 2018 at 11:01 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> FWIW, I've looked at this again. I think that the situation Siva
> reported in the first mail can happen before we get commit 3b2787e.
> That is, gin indexes had had a data corruption bug. I've reproduced
> the situation with PostgreSQL 10.1 and observed that a gin index can
> corrupt.

So, you've recreated the problem with Postgres from before 3b2787e,
but not after 3b2787e? Are you suggesting that 3b2787e might have
fixed it, or that it only hid the problem, or something else?

How did you recreate the problem? Do you have a test case you can share?

> However, gingetbitmap (fortunately?) returned a correct
> result even when the gin index is corrupted.

That's not really surprising.

> I'm not sure how you figured this duplicated item pointers issue out
> but what I got through investigating this issue is that gin indexes
> could return a correct result without no assertion failure even if it
> somewhat corrupted. So maybe having amcheck for gin indexes would
> resolve part of problems.

That seems like a really good idea. As you know, I have misgivings
about this area.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2018-06-13 07:29:42 Re: Server crashed with dense_rank on partition table.
Previous Message Masahiko Sawada 2018-06-13 06:01:46 Re: Duplicate Item Pointers in Gin index