Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.
Date: 2019-08-31 08:04:01
Message-ID: CAH2-WzmshZSrKCUd6z1tEURaOMHE7t8jj6TYarNMmQgpWRURMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 29, 2019 at 10:10 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I see some Valgrind errors on v9, all of which look like the following
> two sample errors I go into below.

I've found a fix for these Valgrind issues. It's a matter of making
sure that _bt_truncate() sizes new pivot tuples properly, which is
quite subtle:

--- a/src/backend/access/nbtree/nbtutils.c
+++ b/src/backend/access/nbtree/nbtutils.c
@@ -2155,8 +2155,11 @@ _bt_truncate(Relation rel, IndexTuple lastleft,
IndexTuple firstright,
{
BTreeTupleClearBtIsPosting(pivot);
BTreeTupleSetNAtts(pivot, keepnatts);
- pivot->t_info &= ~INDEX_SIZE_MASK;
- pivot->t_info |= BTreeTupleGetPostingOffset(firstright);
+ if (keepnatts == natts)
+ {
+ pivot->t_info &= ~INDEX_SIZE_MASK;
+ pivot->t_info |=
MAXALIGN(BTreeTupleGetPostingOffset(firstright));
+ }
}

I'm varying how the new pivot tuple is sized here according to whether
or not index_truncate_tuple() just does a CopyIndexTuple(). This very
slightly changes the behavior of the nbtsplitloc.c stuff, but that's
not a concern for me.

I will post a patch with this and other tweaks next week.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Paul A Jungwirth 2019-08-31 13:35:48 Re: range bug in resolve_generic_type?
Previous Message Oleksii Kliukin 2019-08-31 07:21:37 Re: [HACKERS] Help required to debug pg_repack breaking logical replication