Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: ERROR: invalid memory alloc request size <a_big_number_here>


  • From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
  • To: Matteo Beccati <php(at)beccati(dot)com>
  • Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
  • Subject: Re: ERROR: invalid memory alloc request size <a_big_number_here>
  • Date: Thu, 27 Oct 2005 11:16:01 -0300
  • Message-id: <20051027141601(dot)GD880(at)surnet(dot)cl>

Matteo Beccati wrote:

> #2  0x0827b5cf in MemoryContextAlloc (context=0x856bcc8, 
> size=4278026492) at mcxt.c:505
>         __func__ = "MemoryContextAlloc"
> #3  0x080b6a16 in GetMultiXactIdMembers (multi=320306, xids=0xbfbfaba4) 
> at multixact.c:935
>         pageno = 156
>         prev_pageno = 156
>         entryno = 819
>         slotno = 2
>         offptr = (MultiXactOffset *) 0x286536ac
>         offset = 4235201
>         length = -4235201
>         i = 138425096
>         nextMXact = 320308
>         tmpMXact = 320307
>         nextOffset = 4235265
>         ptr = (TransactionId *) 0xbfbfab78

Whoa.  length = *offptr - offset, which means that the datum stored at
offptr is 0.  I think the problem is that CreateMultiXactId calls
GetNewMultiXactId and then RecordNewMultiXact, and the lock is released
between the calls.  So one backend could try to read the offset before
another one had the time to finish writing it.

-- 
Alvaro Herrera                           Developer, http://www.PostgreSQL.org
"No single strategy is always right (Unless the boss says so)"
                                                  (Larry Wall)



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group