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