From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Markus Wanner <markus(at)bluegap(dot)ch> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Synchronous Log Shipping Replication |
Date: | 2008-09-11 15:41:05 |
Message-ID: | 28487.1221147665@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Markus Wanner <markus(at)bluegap(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2008-09-11 15:50:09 | Re: [Review] pgbench duration option |
Previous Message | Alvaro Herrera | 2008-09-11 15:34:33 | Re: pg_regress inputdir |