> Claudio Natoli <claudio.natoli@memetrics.com> writes:
> > So this means we'll have to pull relHash out of the shared FreeSpaceMap
> > structure and make it a variable in it's own right?
>
> Hm. The freespace.c code is relatively new and might not be jumping
> through all of the hoops it should be jumping through. My
> recollectionof the older code is that the logic was like "create or
> attach to shared memory structure named 'foo', if not create then
initialize the shared
> structure". I'll take the blame if freespace.c doesn't do this right...
The way I see it:
* Postmaster call InitFreeSpaceMap
* When a fork/exec backend starts, it'll be able to access the
FreeSpaceMap struct via shared memory
* But this very same struct contains a pointer (relHash) to a struct
which, in the fork/exec case, is valid only in the postmaster (ie. the hashp
HTAB struct created in the postmaster's DynaHashCxt context and returned by
hash_create/ShmemInitHash)
[of course, this HTABs struct htcl value will point to shared memory, but
it is a moot point by this stage]
> > [Same goes for lockHash and proclockHash in the LockMethod structure
> > reference by "LockTable (lock method table)"]
>
> The lock code *should* be doing this right, unless I've totally
> forgotten the modification history ...
AFAICS, the reasoning above applies to these hashes. Of course, I'm more
than ready to be corrected on this reasoning...
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>