Re: LISTEN/NOTIFY and notification timing guarantees

On Mon, Feb 15, 2010 at 3:31 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I'm not sure how probable it is that applications might be coded in a
> way that relies on the properties lost according to point #2 or #3.

Your observations are all correct as far as I can tell.

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?

> We could fix #2 by not releasing AsyncQueueLock between pages when
> queuing messages. This has no obvious downsides as far as I can see;
> if anything it ought to save some cycles and contention.

Currently transactions with a small number of notifications can
deliver their notifications and then proceed with their commit while
transactions with many notifications need to stay there longer, so the
current behavior is fair in this respect. Changing the locking
strategy makes the small volume transactions wait for the bigger ones.
Also currently readers can already start reading while writers are
still writing (until they hit the first uncommitted transaction of
their database).

> I think preserving the
> property that self-notifies are delivered immediately upon commit might
> be more important than that.

Fine with me, sounds reasonable :-)

Joachim