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.
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> |