Re: notification: pg_notify ?

Gavin Sherry wrote:

> 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.
>

It is not a solution to the whole LISTEN/NOTIFY problem, but it is a
solution to the dead tuples accumulation.

>
>>
>>>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.
>

That highly depends on WHAT-you-want-to-do :)
If the new shared memory implementation will guarantee message delivery
at the same degree as current implementation then it is the-right-way-to-do-it.
If not then let's not broke existing functionality! Let's implement it as an
additional functionality, say FASTNOTIFY or RIGHTNOTIFY ;)
>

> 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

Forgive my ignorance, you mean sending backend?

> to be on the safe side. A buffer overrun (rare as it would be,

Regards,
Mikhail