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 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
pgsql-bugs by date
|Next:||From: Jerome Schulteis||Date: 2011-09-09 20:59:50|
|Subject: BUG #6201: Windows User Log Off Causes Backend Exception 0xC0000142|
|Previous:||From: Heikki Linnakangas||Date: 2011-09-09 15:13:19|
|Subject: Re: BUG #6200: standby bad memory allocations on SELECT|