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
|
Список | 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 по дате отправления: