Обсуждение: pgkill

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.

James

James Mansion <james@mansionfamily.plus.com> writes:
> 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 -

It's not that easy to be sure of either of those conditions.

The notify code needs to be dumped and rewritten from scratch
--- I see little point in marginal optimizations, and none at
all in doing anything while the pg_listener table is still used
as communication mechanism.
        regards, tom lane

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