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)
>
This can happen if we start new split before completing the previous
split of a bucket or if there is still any remaining tuples present in
the bucket being from the previous split. I see a problem in below
code:
_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. However, I wanted to verify that this is the reason why you
are seeing the problem. I could not connect to the database provided
by you.
> Statement was
>
> update public.hash_i4_heap set seqno = public.hash_i4_heap.random;
>
> It can be reproduced with the data directory (Debian stretch amd64) I've
> put here:
>
> http://ansel.ydns.eu/~andreas/_hash_splitbucket_guts.tar.xz (12 MB)
>
> Backtrace below. The cluster hasn't suffered any crashes before this
> incident.
>
How should I connect to this database? If I use the user fdw
mentioned in pg_hba.conf (changed authentication method to trust in
pg_hba.conf), it says the user doesn't exist. Can you create a user
in the database which I can use?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com