[HACKERS] Mechanism to transmit multiple event notifications with one signal

Hi,

On Fri, Sep 12, 2008 at 12:41 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Markus Wanner <markus@bluegap.ch> writes:
>> Tom Lane wrote:
>>> Sooner or later we shall have to bite the bullet and set up a
>>> multiplexing system to transmit multiple event types to backends with
>>> just one signal. We already did it for signals to the postmaster.
>
>> Agreed. However, it's non-trivial if you want reliable queues (i.e. no
>> message skipped, as with signals) for varying message sizes.
>
> No, that's not what I had in mind at all, just the ability to deliver
> one of a specified set of event notifications --- ie, get around the
> fact that Unix only gives us two user-definable signal types.
>
> For signals sent from other backends, it'd be sufficient to put a
> bitmask field into PGPROC entries, which the sender could OR bits into
> before sending the one "real" signal event (either SIGUSR1 or SIGUSR2).
>
> I'm not sure what to do if we need signals sent from processes that
> aren't connected to shared memory; but maybe we need not cross that
> bridge here.
>
> (Also, I gather that the Windows implementation could already support
> a bunch more signal types without much trouble.)

There was discussion of event notification to backends from other process
in the thread, "Synchronous Log Shipping Replication"
(http://archives.postgresql.org/pgsql-hackers/2008-09/msg00802.php).

The problem is that it's difficult to define new event notification using signal
to backends since they already use SIGUSR1 and SIGUSR2. Attached is
a WIP patch for the mechanism to transmit multiple event notifications with
one signal. This mechanism would be useful for various uses, at least
I would use this for implementing synchronous replication.

In this patch,
* I put a bitmask field into PGPROC for the communication of event type
as advised by Tom in the above thread.
* I replaced CatchupInterruptHandler() by new signal handler for SIGUSR1,
adjusted the codes around "catchup interrupt" to this mechanism.
* remaining work is adjusting the comments around "catchup interrupt".

Comments welcome.

Regards,

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