Re: GIN improvements part 1: additional information
От | Tomas Vondra |
---|---|
Тема | Re: GIN improvements part 1: additional information |
Дата | |
Msg-id | 52D478F2.6070005@fuzzy.cz обсуждение исходный текст |
Ответ на | Re: GIN improvements part 1: additional information (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: GIN improvements part 1: additional information
|
Список | pgsql-hackers |
On 13.1.2014 18:07, Alexander Korotkov wrote: > On Sat, Jan 11, 2014 at 6:15 AM, Tomas Vondra <tv@fuzzy.cz > <mailto:tv@fuzzy.cz>> wrote: > > On 8.1.2014 22:58, Alexander Korotkov wrote: > > Thanks for reporting. Fixed version is attached. > > I've tried to rerun the 'archie' benchmark with the current patch, and > once again I got > > PANIC: could not split GIN page, didn't fit > > I reran it with '--enable-cassert' and with that I got > > TRAP: FailedAssertion("!(ginCompareItemPointers(&items[i - 1], > &items[i]) < 0)", File: "gindatapage.c", Line: 149) > LOG: server process (PID 5364) was terminated by signal 6: Aborted > DETAIL: Failed process was running: INSERT INTO messages ... > > so the assert in GinDataLeafPageGetUncompressed fails for some reason. > > I can easily reproduce it, but my knowledge in this area is rather > limited so I'm not entirely sure what to look for. > > > I've fixed this bug and many other bug. Now patch passes test suite that > I've used earlier. The results are so: OK, it seems the bug is gone. However now there's a memory leak somewhere. I'm loading pgsql mailing list archives (~600k messages) using this script https://bitbucket.org/tvondra/archie/src/1bbeb920/bin/load.py And after loading about 1/5 of the data, all the memory gets filled by the pgsql backends (loading the data in parallel) and the DB gets killed by the OOM killer. Tomas
В списке pgsql-hackers по дате отправления: