Re: Listen / Notify - what to do when the queue is full

On 2/18/10 9:58 AM, Simon Riggs wrote:
> I thought a bit more about this and don't really understand why we need
> an xid at all. When we discussed this before the role of a NOTIFY was to
> remind us to refresh a cache, not as a way of delivering a transactional
> payload. If the cache refresh use case is still the objective why does
> it matter whether we commit or not when we issue a NOTIFY? Surely, the
> rare case where we actually abort right at the end of the transaction
> will just cause an unnecessary cache refresh. 

Actually, even for that use, it doesn't wash to have notifies being sent
for transactions which have not yet committed.  Think of cases (and I
have two applications) where data is being pushed into an external
non-transactional cache or queue (like Memcached, Redis or ApacheMQ)
from PostgreSQL on the backend.  If the transaction fails, it's
important that the data not get pushed.

I guess I'm not following why HS would be different from a single server
in this regard, though?

Mind you, this is all 9.1 discussion, no?

--Josh Berkus