Re: LWLock/ShmemIndex startup question

> You have broken stuff before by rearranging the sequence of
operations...

Ah, yeah, well, FWIW, if that is the only thing that gets broken in the
process of making this port, I'll be more than satisfied. Will that be held
against me forever?

> what exactly have you got in mind here?

Moving InitShmemIndex into InitShmemAllocation.

I'd like to make this the first call, inside the context of ShmemBootstrap =
true, and insert logic to avoid SpinLock acquisition/release inside
ShmemAlloc/ShmemInitStruct (when ShmemBootstrap = true). Not pretty, but
I'll trade off the removal of other ugliness (like the
ShmemLock/ShmemIndexLock spinlock memory allocation, which could then just
use ShmemAlloc).

> > ... a possible solution to a Win32 shmem/semaphore bootstrap
> > problem (postgres semaphores under Win32 uses ShmemIndex which uses
> > spinlocks which use shared memory which use semaphores which ...).

> The correct solution to that seems to lie elsewhere, ie, not use
semaphores for spinlocks.

Just working with what we've already got. There seems to be very usable code
in src/backend/port/win32/sema.c, which gets invoked as Win32 does not have
spin-locks, but unfortunately relies on ShmemInitStruct.

If you've got a shorter path in mind, I'm all ears.

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>