Re: Sending notifications from the master to the standby - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Sending notifications from the master to the standby
Date
Msg-id 4F0DDC1C.50609@agliodbs.com
Whole thread Raw
In response to Re: Sending notifications from the master to the standby  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Sending notifications from the master to the standby  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom,

> BTW ... it occurs to me to ask whether we really have a solid use-case
> for having listeners attached to slave servers.  I have personally never
> seen an application for LISTEN/NOTIFY in which the listeners were
> entirely read-only.  Even if there are one or two cases out there, it's
> not clear to me that supporting it is worth the extra complexity that
> seems to be needed.

Actually, I've seen requests for it from my clients and on IRC.  Not
sure how serious those are, but users have brought it up.  Certainly
users intuitively think they should be able to LISTEN on a standby, and
are surprised when they find out they can't.

The basic idea is that if we can replicate LISTENs, then you can use
replication as a simple distributed (and lossy) queueing system.  This
is especially useful if the replica is geographically distant, and there
are a lot of listeners.

The obvious first use case for this is for cache invalidation.  For
example, we have one application where we're using Redis to queue cache
invalidation messages; if LISTEN/NOTIFY were replicated, we could use it
instead and simplify our infrastructure.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


pgsql-hackers by date:

Previous
From: Misa Simic
Date:
Subject: Re: JSON for PG 9.2
Next
From: Peter Eisentraut
Date:
Subject: PL/Python result metadata