Re: BUG #6200: standby bad memory allocations on SELECT - Mailing list pgsql-bugs

From Simon Riggs
Subject Re: BUG #6200: standby bad memory allocations on SELECT
Date
Msg-id CA+U5nML0o-LSKuTY=Rxs0uzdDM=ProMppDE584zc8szS=9Px+A@mail.gmail.com
Whole thread Raw
In response to BUG #6200: standby bad memory allocations on SELECT  ("Daniel Farina" <daniel@heroku.com>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: BUG #6200: standby bad memory allocations on SELECT
Next
From: "Jerome Schulteis"
Date:
Subject: BUG #6201: Windows User Log Off Causes Backend Exception 0xC0000142