Re: Review: support for multiplexing SIGUSR1

Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> On Mon, Jul 27, 2009 at 2:43 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If we want to be able to signal processes that don't have a ProcState
>> entry, it would be better to assign an independent index instead of
>> overloading BackendId like this.

> OK, I'll change the mechanism to assign a ProcSignalSlot to a process,
> independently from ProcState, but similarly to ProcState: a process gets
> a ProcSignalSlot from newly-introduced freelist at startup, and returns it
> to freelist at exit. Since this assignment and return require the lock, I'll
> introduce a new LWLock for them.

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.

>> 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?

> 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.

regards, tom lane