Re: [HACKERS] Memory leak in GIN index build

2016-04-19 Thread Marc Cousin
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

2016-04-18 Thread Julien Rouhaud
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

2016-04-18 Thread Tom Lane
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

2016-04-16 Thread Julien Rouhaud
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

2016-04-16 Thread Tom Lane
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

2016-04-16 Thread Julien Rouhaud
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