Re: Listen / Notify - what to do when the queue is full

On Tue, 2010-01-19 at 19:05 -0500, Tom Lane wrote:
> I guess Joachim is trying to provide a similar guarantee for the new
> implementation, but I'm not clear on why it would require locking.
> The new implementation is broadcast and ISTM it shouldn't require the
> modifying transaction to know which processes are listening.

I think there is a better way. I'll dig into it a little more.

> I haven't read the patch but I agree that the description you give is
> pretty scary from a performance standpoint.  More locks around
> transaction commit doesn't seem like a good idea. 

I was also worried about holding multiple LWLocks at once -- is such
practice generally avoided in the rest of the code?

> If they're only taken
> when an actual LISTEN or NOTIFY has happened in the current transaction,
> that'd be okay (certainly no worse than what happens now) but the naming
> suggested that this'd happen unconditionally.

It appears that the locks are only taken when LISTEN or NOTIFY is
involved.

Regards,
	Jeff Davis