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 | http://candle.pha.pa.us
[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
