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

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Daniel Farina <daniel(at)heroku(dot)com>
Cc: pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #6200: standby bad memory allocations on SELECT
Date: 2011-09-09 15:14:38
Message-ID: CA+U5nML0o-LSKuTY=Rxs0uzdDM=ProMppDE584zc8szS=9Px+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Sep 8, 2011 at 11:33 PM, Daniel Farina <daniel(at)heroku(dot)com> wrote:

>  ERROR: 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().

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jerome Schulteis 2011-09-09 20:59:50 BUG #6201: Windows User Log Off Causes Backend Exception 0xC0000142
Previous Message Heikki Linnakangas 2011-09-09 15:13:19 Re: BUG #6200: standby bad memory allocations on SELECT