On Tue, Jun 12, 2018 at 11:01 PM, Masahiko Sawada <sawada.mshk@gmail.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