Re: postgresql 8 abort with signal 10
От | Alexandre Biancalana |
---|---|
Тема | Re: postgresql 8 abort with signal 10 |
Дата | |
Msg-id | 8e10486b05050309366fc8509c@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: postgresql 8 abort with signal 10 (Vlad <marchenko@gmail.com>) |
Ответы |
Re: postgresql 8 abort with signal 10
Re: postgresql 8 abort with signal 10 |
Список | pgsql-general |
>>You need to find out what's triggering that. Turning on query logging >>would be a good way of investigating. Which directives can I use to enable this ? debug_print_parse ? debug_print_rewritten ? debug_print_plan ? debug_pretty_print ? >>Rather large, shared buffers for a machine with only 1 gig of ram. 640 >>Meg of RAM means the kernel is basically double buffering everything. >>have you tested with smaller settings and this setting was the best? I had 256 of RAM then I increase to 1GB thinking this could be a problem of out of memory or a buggy memory...... After this "upgrade" I increase the numbers of shared buffers,etc It's important to say that the max memory usage reach to only 80%. What values do you suggest ? >>You might want to look in your signal man page on BSD and see what >>signal 10 means. On solaris it's a bus error. Not a clue what it is in >>FreeBSD myself though. FreeBSD man page say: 10 SIGBUS The system does not generate core dump file for this error..... Regards,
В списке pgsql-general по дате отправления: