Claudio Natoli wrote:
> > I think they are saying put the cancel key inside the existing shared
> > memory segment.  
> Ok. Thanks.
> > I don't know when we actually attach to the main shared
> > memory sigment in the child, but it would have to be sooner than when we
> > need the cancel key.
> Yes. Currently, it happens too late.
> I'll put my hand up to have a go at this fixing this (and getting
> processCancelRequest to work under Win32/EXEC_BACKEND at the same time), if
> no one else particularly cares to.
> Just to be clear, this would involve turning the BackendList dlllist into an
> array in shared memory, right? If so, a couple of questions:
>   - what is a suitably large size for this array (2 * MaxBackends, ala
> canAcceptConnections?)
>   - the postmaster makes all calls referencing this list, with the exception
> of processCancelRequest, correct? So, as Tom was alluding to, no locking is
> required (or desired!), and we'll just need to be careful not to introduce a
> race condition into processCancelRequest.

I assumed a much simpler solution.  I thought we would just have:
        struct {
                pid_t   pid;
                int     cancel_key;
        } PidCancel[maxbackend];

in shared memory and we would just sequentially scan looking for a pid
match?  Is that wrong?

  Bruce Momjian                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to