Re: BUG #6200: standby bad memory allocations on SELECT

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #6200: standby bad memory allocations on SELECT
Дата
Msg-id 23550.1327978836@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #6200: standby bad memory allocations on SELECT  (Bridget Frey <bridget.frey@redfin.com>)
Ответы Re: BUG #6200: standby bad memory allocations on SELECT  (Bridget Frey <bridget.frey@redfin.com>)
Список pgsql-bugs
Bridget Frey <bridget.frey@redfin.com> writes:
> The second error is an invalid memory alloc error that we're getting ~2
> dozen times per day in production.  The bt for this alloc error is below.

This trace is consistent with the idea that we're getting a corrupt
tuple out of a table, although it doesn't entirely preclude the
possibility that the corrupt value is manufactured inside the backend.
To get much further you're going to need to look at the specific query
being executed each time this happens, and see if you can detect any
pattern.  Now that you've got debug symbols straightened out, the
gdb command "p debug_query_string" should accomplish this.  (If that
does not produce anything that looks like one of your application's
SQL commands, we'll need to try harder to extract the info.)  You could
probably hack the elog(PANIC) to log that before dying, too, if you'd
rather not manually gdb each core dump.

            regards, tom lane

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #6420: Incorrect description of Postgres time system
Следующее
От: maxim.boguk@gmail.com
Дата:
Сообщение: BUG #6422: User without any priviledges on a table can lock the table from other users in some cases