Skip site navigation (1) Skip section navigation (2)

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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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 21:06:27
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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.

> 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.

It probably would be possible to get the page out of the dump, but
I'd be really surprised if that proved much.  By the time the
crash-dump-making code gets around to examining the shared memory, the
other process that's hypothetically changing the page will have done its
work and moved on.  A crash in process X doesn't freeze execution in
process Y, at least not in any Unixoid system I've ever heard of.

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: Tom LaneDate: 2012-02-01 21:43:34
Subject: Re: BUG #6425: Bus error in slot_deform_tuple
Previous:From: Alvaro HerreraDate: 2012-02-01 21:05:29
Subject: Re: BUG #6425: Bus error in slot_deform_tuple

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group