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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: BUG #6200: standby bad memory allocations on SELECT
Дата
Msg-id 1328146277-sup-6909@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: BUG #6200: standby bad memory allocations on SELECT  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Excerpts from Tom Lane's message of mi=C3=A9 feb 01 18:06:27 -0300 2012:
> Robert Haas <robertmhaas@gmail.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.
>=20
> > 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.
>=20
> 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.

Maybe you can do something like send SIGSTOP to every other backend,
then attach to them and find which one was touching the same buffer,
then peek at what it was doing.

--=20
=C3=81lvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

Предыдущее
От: Sergey Burladyan
Дата:
Сообщение: Re: BUG #6407: Crash on queries to gin index with multiply values
Следующее
От: Sachin Srivastava
Дата:
Сообщение: Re: BUG #6427: Installation stack builder error