On Sat, Dec 3, 2016 at 6:58 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Sat, Dec 3, 2016 at 2:06 AM, Andreas Seltenreich <seltenreich@gmx.de> wrote:
>> Hi,
>>
>> the new hash index code on 11003eb failed an assertion yesterday:
>>
>> TRAP: FailedAssertion("!(bucket == obucket)", File: "hashpage.c", Line: 1037)
>
> _hash_expandtable(Relation rel, Buffer metabuf)
> {
> ..
> if (H_NEEDS_SPLIT_CLEANUP(oopaque))
> {
> /* Release the metapage lock. */
> _hash_chgbufaccess(rel, metabuf, HASH_READ, HASH_NOLOCK);
>
> hashbucketcleanup(rel, old_bucket, buf_oblkno, start_oblkno, NULL,
> metap->hashm_maxbucket, metap->hashm_highmask,
> metap->hashm_lowmask, NULL,
> NULL, true, NULL, NULL);
> ..
> }
>
> Here we shouldn't be accessing meta page after releasing the lock as
> concurrent activity can change these values. This can be fixed by
> storing these values in local variables before releasing the lock and
> passing local variables in hashbucketcleanup(). I will send patch
> shortly.
>
Please find attached patch to fix above code. Now, if this is the
reason of the problem you are seeing, it won't fix your existing
database as it already contains some tuples in the wrong bucket. Can
you please re-run the test to see if you can reproduce the problem?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com