I wrote:
> * Given that the idea is to ignore already-committed entries, it makes
> sense that if LISTEN is called inside a serializable transaction block
> then the cutoff ought to be the transaction's snapshot. Otherwise we'd
> be dropping notifications from transactions that the calling session
> can't have seen the effects of. That defeats the whole point.
> * This says that not only is it okay to use a serializable snapshot
> as the reference, but we *should* do so; that is, it's actually wrong
> to use GetLatestSnapshot here, we should use GetTransactionSnapshot.
> There's not going to be any real difference in read-committed mode,
> but in repeatable-read or serializable mode we are risking dropping
> events that it'd be better to send to the client.
> I'm disinclined to make such a change in the back branches, but it'd
> be reasonable to do so in HEAD.
I spent some time working on this, but then realized that the idea
has a fatal problem. We cannot guarantee receipt of all notifications
since the transaction snapshot, because if our session isn't yet
listening, there's nothing to stop other transactions from trimming
away notify queue entries as soon as all the already-listening sessions
have read them.
One could imagine changing the queue-trimming rules to avoid this,
but I think it's pointless. The right way to use LISTEN is to be
sure you commit it before inspecting database state, and that's
independent of isolation level.
I'd written some documentation and comment changes around this,
claiming falsely that Repeatable Read or Serializable isolation
would now let you make more assumptions about the timing of the
first received notification. I'll get rid of those claims and
just commit the docs changes --- it seems worthwhile to clarify
what is and isn't safe use of LISTEN. But the code should be
left as-is, I'm thinking.
regards, tom lane
