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
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 |