Re: Optimize LISTEN/NOTIFY

I wrote:
> I think that if we have a backend that isn't interested in our
> notifications, and we can't direct-advance it, we should apply
> the same behavior that was previously used for backends in other
> databases. That was basically a conservative approximation to
> "isn't interested", and I don't see why it wouldn't work fine
> when we have a more accurate idea of "isn't interested".

I spent some time trying to measure the impact of that point,
by modifying the test program you posted upthread so that
some notifiers go at full speed while others respond to the
rate-limit switch so that they can be made to go slowly.
I couldn't really see any difference between what you have in v34
and doing this the old way. Maybe I just failed to construct the
right test case to stress this behavior. But anyway, without
concrete evidence for a change I think we should stick to the
old behavior. When that was put in, it was to ameliorate a
demonstrable "thundering herd" problem, and it seems likely to me
that we'll bring that back for some usage patterns if we eagerly
awaken backends that don't really need to do anything right away.

So, here's a reworked v35, which also incorporates quite a lot
of cosmetic modifications as well as some bug fixes (mostly
to do with being sure we recover from foreseeble problems like
OOM partway through commit). I think this is pretty close to
committable, but if you see anything you don't like, let me know.

regards, tom lane