On Wed, 3 Apr 2002, Mikhail Terekhov wrote:
>
>
> Tom Lane wrote:
>
>
> > There is a very significant performance problem with LISTEN/NOTIFY
> > via pg_listener: in any application that generates notifications at
> > a significant rate, pg_listener will accumulate dead tuples at that
> > same rate, and we will soon find ourselves wasting lots of time
> > scanning through dead tuples. Frequent VACUUMs might help, but the
>
>
> That's unfortunate, may be if backend could reuse tuple on updates could help?
There is already a TODO item to address this. But row reuse is the wrong
solution to the problem. See below.
>
>
> > whole thing is really quite silly: why are we using a storage mechanism
> > that's designed entirely for *stable* storage of data to pass inherently
> > *transient* signals? If the system crashes, we have absolutely zero
>
>
>
> Because there is no other easy way to guarantee message delivery?
Shared memory is much easier and, to all intents and purposes, as reliable
for this kind of usage. It is much faster and is the-right-way-to-do-it.
I don't believe that the question 'what happens if there is a buffer
overrun?' is a valid criticism of this approach. In the case of the
backend cache invalidation system, the backends just blow away their cache
to be on the safe side. A buffer overrun (rare as it would be,
considering the different usage patterns of the shared memory for
notification) would result in an elog(ERROR) from within the backend which
has attempted to execute the notification. After all, running out of
memory is an error in this case.
Gavin
