Re: pgkill

James Mansion wrote:
> I was looking at the notify processing in async.c and I noticed that 
> kill is called whether or not the
> process has been signalled already, and whether or not 'this' process 
> has signalled the process.
>
> It seems unecessary to me - especially if we are on Win32 and the 
> pgkill is implemented as
> a CallNamedPipe.
>
> My understanding is that signal is normally a fairly expensive 
> operation at the best
> of times, particularly so when its turned from a fire-and-forget to an 
> RPC with
> scheduling.
>
> I appreciate that signal wishes to determine whether a process is 
> dead, but it must
> be questionable whether this is necessarily something that should be 
> done by peers
> when the information is immediately out of date and we can 
> definitively determine
> a crash in the master process anyway.
>
> So:
>
> 1) why do the RPC, rather than detect death from the master process?
>
> 2) Why not use the existing compare-and-set atomic infrastructure to 
> maintain
> a 'pending signal' flag (or flags) in struct PGPROC and elide signals 
> that are
> flagged and not yet indicated as processed by the target process?
>
> 3) If we do both the above, would it not be cleaner to use an fd with a
> local datagram socket than a signal on nearly all systems?  And a 
> semaphore
> on Win32? So its all picked up in select or WaitForMultipleObjects?
>
> I know the comment in async.c is: 'but we do still send a SIGUSR2 signal,
> just in case that backend missed the earlier signal for some reason.'. 
> But that
> seems somewhat lame - we might have multiple signals compressed but
> does any system actually *lose* them?
>
> It also occurred to me that we should not kill as we go, but accumulate a
> set of pids to signal and then signal each after the iteration is 
> complete so
> we can do as little processing with the pg_notify resources held as 
> possible,
> and certainly no system calls if we can help it.
>


This whole area is due for a revamp, which I am planning on doing as 
part of implementing notification payloads. Work on that will probably 
start in about 2 weeks.

cheers

andrew