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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bridget Frey <bridget(dot)frey(at)redfin(dot)com>, Michael Brauwerman <michael(dot)brauwerman(at)redfin(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #6200: standby bad memory allocations on SELECT
Date: 2012-02-01 17:58:15
Message-ID: CA+Tgmoaecqw4yiBJnkdcrWCys5eCfn4=5ahSqPxy2rcoh=6Kag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Feb 1, 2012 at 11:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> No, I wasn't thinking about a tuple descriptor mismatch.  I was
>> imagining that the page contents themselves might be in flux while
>> we're trying to read from it.
>
> Oh, gotcha.  Yes, that's a horribly plausible idea.  All it'd take is
> one WAL replay routine that hasn't been upgraded to acquire sufficient
> buffer locks.  Pre-hot-standby, there was no reason for them to be
> careful about locking.
>
> On the other hand, if that were the cause, you'd expect the symptoms
> to be a bit more variable...

Well, OP has two: crash, and invalid memory allocation. Both share
the common thread that they happen while trying to decode a tuple.

It would be nice to get a dump of what PostgreSQL thought the entire
block looked like at the time the crash happened. That information is
presumably already in the core dump, but I'm not sure if there's a
nice way to extract it using gdb.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Robert Haas 2012-02-01 18:10:07 Re: BUG #6425: Bus error in slot_deform_tuple
Previous Message Duncan Rance 2012-02-01 17:32:57 Re: BUG #6425: Bus error in slot_deform_tuple