Re: Buildfarm failures for hash indexes: buffer leaks

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Buildfarm failures for hash indexes: buffer leaks
Date: 2018-10-23 10:52:29
Message-ID: CAA4eK1+4YDGubEASqSrZPsPDo12Ds4DmfXAROyLetdr_mp1SwA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 22, 2018 at 1:42 PM Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
> Hello Michaël,
>
> > The first failure is unrelated to the involved commits, as they touched
> > completely different areas of the code:
> > INSERT INTO hash_split_heap SELECT a/2 FROM generate_series(1, 25000) a;
> > + WARNING: buffer refcount leak: [6481] (rel=base/16384/32349, blockNum=156, flags=0x93800000, refcount=1 1)
> >
> > And versions older than HEAD do not complain.
> >
> > Any thoughts?
>
> Both animals use gcc experimental versions, which may rather underline a
> new bug in gcc head rather than an existing issue in pg. Or not.
>

It is possible, but what could be the possible theory? The warning
indicates that somewhere we forgot to call ReleaseBuffer. Today, I
had reviewed at the hash index code related to test case that is
failing but didn't find any obvious problem. What should we our next
step? Do we want to change gcc version and see?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-10-23 11:10:55 Re: Buildfarm failures for hash indexes: buffer leaks
Previous Message Andrey Lepikhov 2018-10-23 10:35:21 Re: Making all nbtree entries unique by having heap TIDs participate in comparisons