Re: Synchronous Log Shipping Replication - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Synchronous Log Shipping Replication
Date
Msg-id 28487.1221147665@sss.pgh.pa.us
Whole thread Raw
In response to Re: Synchronous Log Shipping Replication  (Markus Wanner <markus@bluegap.ch>)
Responses Re: Synchronous Log Shipping Replication  (Markus Wanner <markus@bluegap.ch>)
Re: Synchronous Log Shipping Replication  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
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.)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_regress inputdir
Next
From: Heikki Linnakangas
Date:
Subject: Re: [Review] pgbench duration option