Re: notification: pg_notify ? - Mailing list pgsql-hackers

On Sat, 2002-03-23 at 12:46, Tom Lane wrote:
> Also, the notion that the NOTIFY mechanism can't be lossy misses the
> fact that you've got a perfectly good non-lossy mechanism at hand
> already: user tables.  The traditional way of using NOTIFY has been
> to stick the important data into tables and use NOTIFY simply to
> cue listeners to look in those tables.  I don't foresee this changing;
> it'll simply be possible to give somewhat finer-grain notification of
> what/where to look.  I don't think that forcing NOTIFY to have the
> same kinds of semantics as SQL tables do is the right design approach.
> IMHO the only reason NOTIFY exists at all is to provide a simpler,
> higher-performance communication pathway than you can get with tables.

Okay, I agree (of course, it would be nice to have a more reliable
NOTIFY mechanism, but I can't see of a way to implement a
high-performance, reliable mechanism without at least one serious
drawback). And as you rightly point out, there are other methods for
people who need more reliability.

So the new behavior of NOTIFY should be: when the notifying backend
commits its transaction, the notification is stored in a shared memory
buffer of fixed size, and the listening backend is sent a SIGUSR2. If
the shared memory buffer is full, it is completely emptied. In the
listening backend's SIGUSR2 signal handler, a flag is set and the
backend goes back to its current transaction. When it becomes idle, it
checks the shared buffer: if it can't find any matching elements in the
buffer, it knows an overrun has occurred. When informing the front-end,
a notification that results from an overrun is signified by a
notification with a NULL message and with the PID of the notifying
backend sent to some constant (say, -1). This informs the front-end that
an overrun has occurred, so it can take appropriate action.

Is this behavior acceptable to everyone?

I can see 1 potential problem: there is a race condition in the "detect
an overrun" logic. If an overrun occurs and the buffer is flushed but
then another notification for one of the listening backends arrives, a
backend will only inform the front-end about the most recent
notification: there will be no indication that an overrun occurred, or
that there were other legitimate notifications in the buffer before the
overrun. It would be nice to be able to tell clients 100% "an overrun
just occurred, be careful", but apparently that's not even possible.

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC