Re: Listen / Notify - what to do when the queue is full - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Listen / Notify - what to do when the queue is full
Date
Msg-id 4B7D82BC.70207@agliodbs.com
Whole thread Raw
In response to Re: Listen / Notify - what to do when the queue is full  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Listen / Notify - what to do when the queue is full
Next
From: Merlin Moncure
Date:
Subject: Re: Listen / Notify - what to do when the queue is full