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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bridget Frey <bridget(dot)frey(at)redfin(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Brauwerman <michael(dot)brauwerman(at)redfin(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6200: standby bad memory allocations on SELECT
Date: 2012-01-31 03:00:36
Message-ID: 23550.1327978836@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Bridget Frey <bridget(dot)frey(at)redfin(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message maxim.boguk 2012-01-31 03:41:19 BUG #6422: User without any priviledges on a table can lock the table from other users in some cases
Previous Message Tom Lane 2012-01-31 02:21:42 Re: BUG #6420: Incorrect description of Postgres time system