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

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: 2005-10-27 14:16:01
Message-ID: 20051027141601.GD880@surnet.cl (view raw or flat)
Thread:
Lists: pgsql-hackers
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)

In response to

Responses

pgsql-hackers by date

Next:From: Matteo BeccatiDate: 2005-10-27 14:18:43
Subject: Re: ERROR: invalid memory alloc request size <a_big_number_here>
Previous:From: Alvaro HerreraDate: 2005-10-27 14:13:19
Subject: Re: ERROR: invalid memory alloc request size <a_big_number_here>

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group