Re: Buildfarm failures for hash indexes: buffer leaks - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Buildfarm failures for hash indexes: buffer leaks
Date
Msg-id CAA4eK1+4YDGubEASqSrZPsPDo12Ds4DmfXAROyLetdr_mp1SwA@mail.gmail.com
Whole thread Raw
In response to Re: Buildfarm failures for hash indexes: buffer leaks  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: Buildfarm failures for hash indexes: buffer leaks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Oct 22, 2018 at 1:42 PM Fabien COELHO <coelho@cri.ensmp.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


pgsql-hackers by date:

Previous
From: Andrey Lepikhov
Date:
Subject: Re: Making all nbtree entries unique by having heap TIDs participatein comparisons
Next
From: Tom Lane
Date:
Subject: Re: Buildfarm failures for hash indexes: buffer leaks