Re: BUG #16619: Amcheck detects corruption in hstore' btree index (ver 2)

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, andrewbille(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16619: Amcheck detects corruption in hstore' btree index (ver 2)
Date: 2020-09-16 21:55:26
Message-ID: CAPpHfduwMnf+mRuSHo7LgcMu_FciAK+2LWCB4wwfEBhPW=kzjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi, Peter!

On Wed, Sep 16, 2020 at 8:47 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Wed, Sep 16, 2020 at 7:24 AM Anastasia Lubennikova
> <a(dot)lubennikova(at)postgrespro(dot)ru> wrote:
> > For v2 indexes pivot tuple's offset can contain any random number which
> > will lead to bt_pivot_tuple_identical() failure.
> >
> > The fix is pretty simple - only compare data part of the tuples. I think
> > we can skip offnum check for all index versions to keep the code simple.
>
> I pushed a tweaked version of this patch. It seemed worth preserving
> the inclusion of offset number in the bt_pivot_tuple_identical()
> memcmp() comparison. The field contains important metadata that really
> should match. Also, I made sure to compare t_info field on all indexes
> (including pg_upgrade'd indexes) for the same reason.
>
> We already account for heapkeyspace difference in other similar
> routines, such as invariant_l_offset(). It's not hard to do this here
> as well.

I was going to tweak this patch in a similar way, but made it in
advance. Your commit looks good to me, thanks!

------
Regards,
Alexander Korotkov

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Peter Geoghegan 2020-09-16 22:29:50 Re: BUG #16619: Amcheck detects corruption in hstore' btree index (ver 2)
Previous Message Max Vikharev 2020-09-16 20:50:25 Re: BUG #16620: Autovacuum does not process certain databases after migration from postgresql 10