Re: 9.1.11 - many backends in "semtimedop" syscall

Поиск
Список
Период
Сортировка
От hubert depesz lubaczewski
Тема Re: 9.1.11 - many backends in "semtimedop" syscall
Дата
Msg-id 20140310153243.GA30595@depesz.com
обсуждение исходный текст
Ответ на Re: 9.1.11 - many backends in "semtimedop" syscall  (hubert depesz lubaczewski <depesz@depesz.com>)
Ответы Re: 9.1.11 - many backends in "semtimedop" syscall  (Thom Brown <thom@linux.com>)
Список pgsql-general
On Thu, Mar 06, 2014 at 06:03:54PM +0100, hubert depesz lubaczewski wrote:
> On Thu, Mar 06, 2014 at 12:02:50PM -0500, Tom Lane wrote:
> > hubert depesz lubaczewski <depesz@depesz.com> writes:
> > > I didn't have a chance to do it. Can try if there is a way to get trace
> > > *without* making core (sorry, my c/gdb knowledge is very, very limited).
> >
> > Sure, you just attach to the process:
> >
> >     $ gdb /path/to/postgres PID-of-process
> >     gdb> bt
> >     gdb> quit
> >
> > This is usually preferable to forcing a core dump.
>
> Thank you. If the problem will strike again, I will do it on all (or
> most, depending how fast I can make it) backends.

The problem did happen again, and we were able to find a fix (I think).
For some reason we had a table with over 50000 (yes, 50 thousand)
indexes on it. This table was a bucardo internals table, so maybe it was
something in bucardo (we are using it to migrate hundreds of tables to
another machine, so maybe it has something to do with it.

Anyway - after removing obsolete indexes there - the problem is gone.

Best regards,

depesz


Вложения

В списке pgsql-general по дате отправления:

Предыдущее
От: Tim Kane
Дата:
Сообщение: Re: Playing with 9.4devel - unnest
Следующее
От: Thom Brown
Дата:
Сообщение: Re: 9.1.11 - many backends in "semtimedop" syscall