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

greg@turnstep.com ("Greg Sabino Mullane") writes:
>> BTW, did we discuss the issue of 2PC transactions versus notify?
>> The current behavior of 2PC with notify is pretty cheesy and will
>> become more so if we make this change --- you aren't really
>> guaranteed that the notify will happen, even though the prepared
>> transaction did commit.  I think it might be better to disallow
>> NOTIFY inside a prepared xact.
>
> That's a tough one. On the one hand, simply stating that NOTIFY and 2PC
> don't play together in the docs would be a straightforward solution
> (and not a bad one, as 2PC is already rare and delicate and should not
> be used lightly). But what I really don't like the is the idea of a
> notify that *may* work or may not - so let's keep it boolean: it either
> works 100% of the time with 2PC, or doesn't at all. Should we throw
> a warning or error if a client attempts to combine the two?

+1 from me...

It should either work, or not work, as opposed to something
nondeterministic.

While it's certainly a nice thing for features to be orthogonal, and for
interactions to "just work," I can see making a good case for NOTIFY and
2PC not playing together.
-- 
select 'cbbrowne' || '@' || 'gmail.com';
http://linuxfinances.info/info/slony.html
Why isn't phonetic spelled the way it sounds?