Here is a proposed patch pursuant to the idea of turning ShmemIndexLock into an LWLock instead of a spinlock, as discussed last week. I remember now that we tried to do that before, and found out it was a pain in the neck :-(. The problem is that you can't use LWLocks until you have a PGPROC, and in the existing code backends don't acquire a PGPROC until down inside InitPostgres. So some rearrangement of the startup sequence is needed to make this work.
What I've done in the attached patch is to split InitProcess into two parts, one that just creates a PGPROC (and is actually pretty comparable to InitDummyProcess) and one that inserts the PGPROC into the shared ProcArray. So a backend that has done just the first part is in a state comparable to the way that dummy processes run for their entire existence: it has a PGPROC but is not a member of ProcArray or the sinval ring. This means it can grab LWLocks, but can't run transactions. InitProcessPhase2 is still called from the same place in InitPostgres, but InitProcess is moved elsewhere: in the ExecBackend case it's done in SubPostmasterMain before calling CreateSharedMemoryAndSemaphores, and otherwise it's done wherever convenient. I found I also had to move the on_exit_reset calls, because that has to happen before InitProcess, else we lose the shutdown callback that it has to install for releasing the PGPROC. Lastly, I split BackendRun into two parts, so that SubPostmasterMain could perform client authentication before it runs InitProcess. This avoids holding a PGPROC before we know the client is legit. (I could alternatively have put the InitProcess call into the middle of BackendRun, but this seemed cleaner.) One advantage of doing this is that autovac is able to acquire its PGPROC before it does the work of deciding which database to attach to. This has no immediate use but it might allow future improvements, such as inspecting the free space map while deciding which database to look at. But other than that, this is kind of ugly :-(. Any opinions whether to apply it, or leave things as they are? regards, tom lane
---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org