Re: LISTEN/NOTIFY and notification timing guarantees

Joachim Wieland <joe(at)mcknight(dot)de> writes:
> One question regarding #2: Is a client application able to tell
> whether or not it has received all notifications from one batch? i.e.
> does PQnotifies() return NULL only when the backend has sent over the
> complete batch of notifications or could it also return NULL while a
> batch is still being transmitted but the client-side buffer just
> happens to be empty?

That's true, it's difficult for the client to be sure whether it's
gotten all the available notifications. It could wait a little bit
to see if more arrive but there's no sure upper bound for how long
is enough. If you really need it, though, you could send a query
(perhaps just a dummy empty-string query). In the old implementation,
the query response would mark a point of guaranteed consistency in the
notification responses: you would have gotten all or none of the
messages from any particular sending transaction, and furthermore
there could not be any missing messages from transactions that committed
before one that you saw a message from.

The latter property is probably the bigger issue really, and I'm afraid
that even with contiguous queuing we'd not be able to guarantee it, so
maybe we have a problem even with my proposed #2 fix. Maybe we should
go back to the existing scheme whereby a writer takes a lock it holds
through commit, so that entries in the queue are guaranteed to be in
commit order. It wouldn't lock out readers just other writers.

regards, tom lane