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

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: BUG #6200: standby bad memory allocations on SELECT
Дата
Msg-id CA+U5nML0o-LSKuTY=Rxs0uzdDM=ProMppDE584zc8szS=9Px+A@mail.gmail.com
обсуждение исходный текст
Ответ на BUG #6200: standby bad memory allocations on SELECT  ("Daniel Farina" <daniel@heroku.com>)
Список pgsql-bugs
On Thu, Sep 8, 2011 at 11:33 PM, Daniel Farina <daniel@heroku.com> wrote:

> =A0ERROR: invalid memory alloc request size 18446744073709551613

> At least once, a hot standby was promoted to a primary and the errors seem
> to discontinue, but then reappear on a newly-provisioned standby.

So the query that fails is a btree index on a hot standby. I don't
fully accept it as an HS bug, but lets assume that it is and analyse
what could cause it.

The MO is certain user queries, only observed in HS. So certain
queries might be related to the way we use indexes or not.

There is a single and small difference between how a btree index
operates in HS and "normal" operation, which relates to whether we
kill tuples in the index. That's simple code and there's no obvious
bugs there, nor anything that specifically allocates memory even. So
the only bug that springs to mind is something related to how we
navigate hot chains with/without killed tuples. i.e. the bug is not
actually HS related, but is only observed under conditions typical in
HS.

HS touches almost nothing else in user space, apart from snapshots. So
there could be a bug there also, maybe in CopySnapshot().

--=20
=A0Simon Riggs=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 http:/=
/www.2ndQuadrant.com/
=A0PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: BUG #6200: standby bad memory allocations on SELECT
Следующее
От: "Jerome Schulteis"
Дата:
Сообщение: BUG #6201: Windows User Log Off Causes Backend Exception 0xC0000142