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  (Tomas Vondra <tv@fuzzy.cz>)
Список 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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Disallow arrays with non-standard lower bounds
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: plpgsql.consistent_into