Re: Review: support for multiplexing SIGUSR1

Hi,

On Tue, Jul 28, 2009 at 12:09 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think you're making things more complicated when they should be
> getting simpler.
>
> It strikes me that the current API of "pass the BackendId if known or
> InvalidBackendId if not" still works for processes without a BackendId,
> as long as you can tolerate a bit of extra search overhead for them.
> (You could reduce the search overhead by searching the array back to
> front.)  So a new process index may be overkill.

Yeah, this is very simple. I'll change the patch according to your suggestion.

Such extra search wouldn't be problem. Because an auxiliary process doesn't
need a catchup and notify interrupt which are intended uses. Also, because
there are few opportunities to send a multiplexed signal to an auxiliary process
in Synch Rep.

>>> Do we have a clear idea of what the future applications are?
>
>> Yes, I'm planning to use this mechanism for communication between
>> a process which can generate the WAL records and a WAL sender process,
>> in Synch Rep. Since not only a backend but also some auxiliary processes
>> (e.g., bgwriter) can generate the WAL records, processes which don't have
>> a ProcState need to receive the multiplexed signal, too.
>
> Huh?  Wouldn't the bgwriter be *sending* the signal not receiving it?

The bgwriter sends and receives a signal to/from the walsender process.

The walsender is new introduced process in Synch Rep, and there are
some free signals which aren't assigned yet. So, the signal sent from a
backend or an auxiliary process to the walsender doesn't need to be
multiplexed.

On the other hand, the signal sent to a backend which has no free signal
must be multiplexed. Since I'd like to treat a backend and an auxiliary
process as unified destination of a signal, I'd like to multiplex also a signal
sent to an auxiliary process. Of course, though we can change the method
of signaling according to the destination (e.g., call a native kill instead of
newly-introduced SendProcSignal when the destination is the bgwriter),
it seems to be awkward.

>> Umm... the patch should cover a notify interrupt which currently uses
>> SIGUSR2?
>
> Getting rid of the separate SIGUSR2 handler would definitely be a good
> proof of concept that the mechanism works for more than one use.

OK. I'll change the patch as above.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center