Skip site navigation (1) Skip section navigation (2)

Re: LISTEN/NOTIFY and notification timing guarantees

From: Joachim Wieland <joe(at)mcknight(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: LISTEN/NOTIFY and notification timing guarantees
Date: 2010-02-15 11:33:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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  :-)


In response to


pgsql-hackers by date

Next:From: marcin mankDate: 2010-02-15 11:34:44
Subject: Re: [COMMITTERS] pgsql: Speed up CREATE DATABASE by deferring the fsyncs until after
Previous:From: Tim BunceDate: 2010-02-15 11:32:57
Subject: Re: CommitFest Status Summary - 2010-02-14

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group