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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Matteo Beccati <php(at)beccati(dot)com>,Martijn van Oosterhout <kleptog(at)svana(dot)org>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: ERROR: invalid memory alloc request size <a_big_number_here>
Date: 2005-10-27 15:57:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > 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.
> Ugh, yes, that is clearly a hole :-( even if it turns out not to explain
> Matteo's observation.
> I don't see any easy way to fix this except by introducing a lot more
> locking than is there now --- ie, holding the MultiXactGenLock until the
> new mxact's starting offset has been written to disk.  Any better ideas?

Well, it isn't a very good solution because it requires us to retain the
MultiXactGenLock past a XLogInsert and some I/O on SLRU pages.
Previously the lock was mostly only used in short operations and very
rarely held during I/O.  But I don't see any other solution either.
Patch attached.

I confess being attracted to Martijn's idea of looping until the correct
answer is obtained.  I don't think it's even too difficult to implement.
But I wonder if there's some hidden pitfall.

Thanks to Matteo for finding the bug!

Alvaro Herrera                      
"El número de instalaciones de UNIX se ha elevado a 10,
y se espera que este número aumente" (UPM, 1972)

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2005-10-27 16:08:05
Subject: Re: Ideas for easier debugging of backend problems
Previous:From: Martijn van OosterhoutDate: 2005-10-27 15:11:41
Subject: Re: Ideas for easier debugging of backend problems

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