Re: fork/exec problem: DynaHashCxt

> I'm not sure if you're confusing backend-local hashes with shared
> hashes, or hash control headers with the actual shared data.  But
> the above is a false statement.  DynaHashCxt is not shared.

No, wasn't confused over that. Was confused over something else though :-)


> Shared hashes are a bit tricky because there is a backend-local
> structure that has a pointer into the shared memory --- is that
> what's confusing you?

That's pretty much right on the mark, and the heart of the problem I
suspect.

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? [Same goes for lockHash
and proclockHash in the LockMethod structure reference by "LockTable (lock
method table)"]


> Keep in mind that this code did work in a fork/exec context not
> so many moons ago.  If you think you see a showstopper, it's a
> relatively recent change and can be undone.

Keeping this firmly in mind, trust me.

Thanks,
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>