From: | "Maurice Gittens" <mgittens(at)gits(dot)nl> |
---|---|
To: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su>, "David Gould" <dg(at)illustra(dot)com> |
Cc: | <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Its not my fault. Its SEG's FAULT! |
Date: | 1998-04-03 10:27:00 |
Message-ID: | 002701bd5eeb$09d7b920$fcf3b2c2@caleb..gits.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>No! In GC-like allocation mode I meant to use malloc to allocate
>memory in big chunks (> 8K) and use Last_Allocated_Byte counter for
>each chunk in palloc() to "allocate" memory. pfree will do nothing.
>GC-destroyer will just free a few chunks - without any scans.
>Many GC-storages will be available simultaneously (GC_Storage_Identifier
>will be returned by StartGCAllocation() call and used by EndGCAllocation()
>to free memory in given storage). GC-allocations will be made in current
memory
>context (in term of postgres) ==> code using special memory contexts
>(relation cache etc) will not be affected at all (switching to another
>context will stop GC-allocation untill first context restored)
>as well elog(ERROR) clean up feature.
>
This seems like an effective strategy too me. It also provides a solution
to the 8 byte alignment problem.
With regards from Maurice.
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim B. Mikheev | 1998-04-03 11:19:39 | Re: [HACKERS] Its not my fault. Its SEG's FAULT! |
Previous Message | Vadim B. Mikheev | 1998-04-03 09:35:26 | Re: [HACKERS] Its not my fault. Its SEG's FAULT! |