Merlin Moncure <mmonc...@gmail.com> writes:
> On Thu, Feb 18, 2010 at 12:58 PM, Simon Riggs <si...@2ndquadrant.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
