Bruce Momjian <[EMAIL PROTECTED]> writes: > Uh, why would you need more than maxbackends? Can't it be indexed by > slot number --- each backend has a slot? Maybe I am missing something.
The postmaster has no way to know what slot number each backend will get. For that matter, a sub-postmaster doesn't know yet either. I think the simplest way to make this work is to use an array that's 2*MaxBackend items long (corresponding to the max number of children the postmaster will fork). Establish the convention that unused entries are zero. Then: 1. On forking a child, the postmaster scans the array for a free (zero) slot, and stashes the cancel key and PID there (in that order). 2. On receiving a child-termination report, the postmaster scans the array for the corresponding entry, and zeroes it out (PID first). (Obviously these algorithms could be improved if they turn out to be bottlenecks, but for the first cut KISS is applicable.) 3. To find or check a cencel key, a sub-postmaster scans the array looking for the desired PID (either its own, or the one it got from an incoming cancel request message). There is a potential race condition if a sub-postmaster scans the array before the postmaster has been able to store its PID there. I think it is sufficient for the sub-postmaster to sleep a few milliseconds and try again if it can't find its own PID in the array. There is no race condition possible for the ProcessCancelRequest case --- the sub-postmaster that spawned an active backend must have found its entry before it could have sent the cancel key to the client, so any valid cancel request from a client must reference an already-existing entry in the array. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match