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

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Matteo Beccati <php(at)beccati(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: ERROR: invalid memory alloc request size <a_big_number_here>
Date: 2005-10-27 14:34:48
Message-ID: 20051027143446.GJ4259@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 27, 2005 at 10:23:07AM -0400, 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?

I don't see immediatly if it's feasible or not. But another approach is
to detect when it happened, and retry. Parts of the buffer code do this
for example...

Hope this helps,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-10-27 14:41:08 Re: Ideas for easier debugging of backend problems
Previous Message Tom Lane 2005-10-27 14:23:07 Re: ERROR: invalid memory alloc request size <a_big_number_here>