Re: [HACKERS] Memory leak in GIN index build

I had the possibility to perform tests on 9.5, and can confirm the memory leak I was seeing is solved with the patch (and that's great :) ) Regards Marc On 18/04/2016 17:53, Julien Rouhaud wrote: > On 18/04/2016 16:33, Tom Lane wrote: >> I poked at this over the weekend, and got more unhappy

Re: [HACKERS] Memory leak in GIN index build

On 18/04/2016 16:33, Tom Lane wrote: > > I poked at this over the weekend, and got more unhappy the more I poked. > Aside from the memory leakage issue, there are multiple coding-rule > violations besides the one you noted about scope of the critical sections. > One example is that in the

Re: [HACKERS] Memory leak in GIN index build

Julien Rouhaud writes: > On 16/04/2016 20:45, Tom Lane wrote: >> I think this needs to be redesigned so that the critical section and WAL >> insertion calls all happen within a single straight-line piece of code. >> >> We could try making that place be

Re: [HACKERS] Memory leak in GIN index build

On 16/04/2016 20:45, Tom Lane wrote: > Julien Rouhaud writes: > >> Also, in dataPlaceToPageLeaf() and ginVacuumPostingTreeLeaf(), shouldn't >> the START_CRIT_SECTION() calls be placed before the xlog code? > > Yeah, they should. Evidently somebody kluged it to avoid

Re: [HACKERS] Memory leak in GIN index build

Julien Rouhaud writes: > After some digging, the leak comes from walbufbegin palloc in > registerLeafRecompressWALData(). > IIUC, walbufbegin isn't pfree-d and can't be before XLogInsert() is > called, which happens in ginPlaceToPage(). Hmm. > I don't see a simple way

[HACKERS] Memory leak in GIN index build

Hello, Another colleague provided a report of memory leak, during a GIN index build. Test case to reproduce the attached (need to create a gin index on the val column after loading). Sorry, it generates a 24GB table, and memory start leaking with a 1GB maintenance_work_mem after reaching 8 or 9

Re: [HACKERS] memory leak in GIN

Jeff Janes writes: > I bisected it down to: > d88976cfa1302e8dccdcbfe55e9e29faee8c0cdf is the first bad commit > commit d88976cfa1302e8dccdcbfe55e9e29faee8c0cdf > Author: Heikki Linnakangas > Date: Wed Feb 4 17:40:25 2015 +0200 > Use a

Re: [HACKERS] memory leak in GIN

On Fri, Mar 11, 2016 at 11:40 PM, Jaime Casanova wrote: > Hi, > > On the spanish list, Felipe de Jesús Molina Bravo, reported a few days > back that a query that worked well in 9.4 consume all memory in 9.5. > With the self contained test he provided us i