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

On Thu, Feb 18, 2010 at 12:58 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote:
>> Joachim Wieland <joe(at)mcknight(dot)de> writes:
>> > We could probably fake this on the Hot Standby in the following way:
>>
>> > We introduce a commit record for every notifying transaction and write
>> > it into the queue itself. So right before writing anything else, we
>> > write an entry which informs readers that the following records are
>> > not yet committed. Then we write the actual notifications and commit.
>> > In post-commit we return back to the commit record and flip its
>> > status.
>>
>> This doesn't seem likely to work --- it essentially makes commit non
>> atomic.  There has to be one and only one authoritative reference as
>> to whether transaction X committed.
>
> 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.

For example, one of those things could be for the client to shut down.
If the server errors out of the transaction that set up the client to
shut down, you probably wouldn't want the client to shut down. I
don't think that's a big deal really, but it conflicts with the old
behavior.

However, being able to send notifications immediately (not at end of
transaction) would be exceptionally useful in some cases. This
happens when the notifying backend is waiting on some sort of response
from the notified client. If you could NOTIFY IMMEDIATELY, then you
could ping the client and get the response in a single transaction
without using dblink based hacks.

merlin