From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Christopher Browne <cbbrowne(at)gmail(dot)com> |
Cc: | Greg Jaskiewicz <gryzman(at)mac(dot)com>, "pgsql-hackers(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Listen/notify across clusters |
Date: | 2013-07-10 18:26:48 |
Message-ID: | 51DDA768.7080004@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/10/2013 09:27 AM, Christopher Browne wrote:
> The act of requesting to LISTEN requires doing a sort of update to the
> database. In elder versions, it put tuple(s) into pg_catalog.pg_listener,
> and that's Right Well Disallowed on a WAL-based replica.
>
> I would think that if you're keen on building an "event detection
> substrate," particularly one that's supposed to cross clusters, then you
> should consider using something actually attuned to that, such as a message
> queueing system, whether an AMQP implementation such as RabbitMQ, or a
> message bus like Spread. If you do that, then you can do this in much
> broader cross-cluster ways for unrelated Postgres clusters.
Huh? LISTEN/NOTIFY across replication has been a desired feature since
we introduced streaming replication. We want it, there's just no
obvious way to do it.
Your email kinda implies that it's not desirable.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2013-07-10 19:21:23 | Re: changeset generation v5-01 - Patches & git tree |
Previous Message | Josh Berkus | 2013-07-10 17:46:48 | Re: Millisecond-precision connect_timeout for libpq |