Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)
Дата
Msg-id 12906.1232210118@sss.pgh.pa.us
обсуждение исходный текст
Ответ на MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)  (Simon Riggs <simon@2ndQuadrant.com>)
Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> Can we add something to memory contexts to make this fail every time?

No, not really.  AFAICS the reason for Alvaro not seeing it must be that
on his machine the new transaction happens to allocate its
TopTransactionContext control block right in the same place where the
old one was.

We could have a debugging mode in which pfree'd space is never recycled
for reuse (just filled with 0xdeadbeef or whatever and left to sit).
But it would not be practical for anything except short debugging
sessions.  In fact, for a case like this, only *very* short debugging
sessions, because you couldn't even recycle after transaction commit.
So the chance of finding problems in seldom-exercised code paths, as
this one is, would be pretty small anyway.
        regards, tom lane


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

Предыдущее
От: "Brendan Jurd"
Дата:
Сообщение: Re: pg_dump versus views and opclasses
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: MemoryContextSwitchTo (Re: [GENERAL] Autovacuum daemon terminated by signal 11)