On Sat, Dec 3, 2016 at 6:58 AM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Sat, Dec 3, 2016 at 2:06 AM, Andreas Seltenreich <seltenre...@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
fix_hash_bucketsplit_sqlsmith_v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
