Re: ERROR: invalid memory alloc request size

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: ERROR: invalid memory alloc request size
Дата
Msg-id 24638.1130452755@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: ERROR: invalid memory alloc request size  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: ERROR: invalid memory alloc request size  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: ERROR: invalid memory alloc request size  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Re: ERROR: invalid memory alloc request size  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> Ok.  I had hoped to reproduce the problem with pristine sources, in
> order to verify that I was able to show it not appearing with my patch.
> However I have been unable to create a situation in which the problem
> appears.  So I attach the patch that I came up with.  Please test it.

On further reflection, this isn't gonna work :-(.  The problem with the
waste-a-slot approach is that it creates an ambiguity near the offsets
wraparound point: if you are looking at an mxid with starting offset
just under 2^32, and you see the next mxid has start offset 1, did your
mxid include the xid in offset 0 or not?

We could possibly fix that by decreeing that wrapped-around mxids never
use slot 0, but it seems pretty darn messy: that would affect fetching
and storing loops as well as the code that allocates space.

I'm currently experimenting with an alternative approach, which leaves
the nextOffset arithmetic as it was and instead special-cases the zero
offset case this way:
    * 2. The next multixact may still be in process of being filled in:    * that is, another process may have done
GetNewMultiXactIdbut not yet    * written the offset entry for that ID.  In that scenario, it is    * guaranteed that
theoffset entry for that multixact exists (because    * GetNewMultiXactId won't release MultiXactGenLock until it does)
  * but contains zero (because we are careful to pre-zero offset pages).    * So, if we read zero as the next multixact
offset,we have to treat    * it with suspicion.  It could be valid, though.  We deal with this    * ambiguity by
requiringprocesses that are creating a multixact with    * starting offset zero to set the creatingOffsetZero flag in
theshared    * data structure; we sleep until we see that cleared before trusting    * a zero offset.  This is all
prettymessy, but the mess occurs only    * in infrequent corner cases, so it seems better than holding the    *
MultiXactGenLockfor a long time on every multixact creation.
 

creatingOffsetZero will be a bool that gets set before releasing
MultiXactGenLock if offset 0 is being returned, and then we clear it
after updating the slru data structures if we had starting offset 0.

Thoughts?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: gj
Дата:
Сообщение: Re: _penalty gist method invoked with one key NULL
Следующее
От: Gregory Maxwell
Дата:
Сообщение: Re: enums