Re: Amcheck verification of GiST and GIN

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Tomas Vondra <tomas(at)vondra(dot)me>, Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Alexander Lakhin <exclusion(at)gmail(dot)com>, Andrey Borodin <amborodin86(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Jose Arthur Benetasso Villanova <jose(dot)arthur(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Amcheck verification of GiST and GIN
Date: 2025-02-21 20:50:21
Message-ID: 6A34B636-6670-45BA-89E9-0A7601ADF326@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Feb 21, 2025, at 12:16 PM, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
> The pgbench script is not corrupting anything overtly, so this looks to either be a bug in gin or a bug in the check.

I suspected the AccessShareLock taken by verify_gin() might be too weak, and upgraded that to ShareRowExclusiveLock so as to prevent the concurrent table modifications (and incidentally other concurrent verify_gin() calls), but to my surprise that didn't fix anything. Even AccessExclusiveLock doesn't fix it. So this seems to either be a bug in the checking code complaining about perfectly valid tuple order, or a bug in Gin corrupting its own entry tree page.

On successive runs, (instrumented to print out a bit more info), there doesn't seem to be any obvious pattern in where the corruption occurs. The offset in the page changes, neither always being at the beginning, nor always at the maxoff; likewise the block where corruption is detected changes from run to run. I've noticed that the rightlink for the page is always the page's block number plus one, but that might just be that I haven't run enough iterations yet to see counter-examples.

Could one of the patch authors take a look? I don't have the time to chase this to conclusion just now. Thanks.


Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-02-21 20:57:20 Re: Statistics Import and Export
Previous Message Tom Lane 2025-02-21 20:49:10 Re: Statistics Import and Export