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

Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Thu, Feb 18, 2010 at 12:58 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> 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.

> notifications serve many more purposes than cache refreshes...it's a
> generic 'wake up and do something' to the client.

The point to my mind is that the previous implementation guaranteed that
failed transactions would not send notifies. I don't think we can just
drop that semantic consistency statement and not break applications.

Also, as Josh notes, even for cache refresh uses it is *critical* that
the notifies not be delivered to listeners till after the sender
commits; else you have race conditions where the listeners look for
changes before they can see them. So it's difficult to make it
much simpler than this anyhow.

regards, tom lane