Horton
Menu

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

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Joachim Wieland <joe@mcknight.de>
Cc: Greg Smith <greg@2ndquadrant.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, "Florian G. Pflug" <fgp@phlo.org>, Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org
Date: 2010-01-19T23:41:29Z
Lists: pgsql-hackers 
On Wed, 2009-12-09 at 11:43 +0100, Joachim Wieland wrote:
> Examples:
> 
> Backend 1:                    Backend 2:
> 
> transaction starts
> NOTIFY foo;
> commit starts
>                               transaction starts
>                               LISTEN foo;
>                               commit starts
>                               commit to clog
> commit to clog
> 
> => Backend 2 will receive Backend 1's notification.

How does the existing notification mechanism solve this problem? Is it
really a problem? Why would Backend2 expect to receive the notification?

> 
> Backend 1:                    Backend 2:
> 
> transaction starts
> NOTIFY foo;
> commit starts
>                               transaction starts
>                               UNLISTEN foo;
>                               commit starts
>                               commit to clog
> commit to clog
> 
> => Backend 2 will not receive Backend 1's notification.

This is the same problem, except that it doesn't matter. A spurious
notification is not a bug, right?

Regards,
	Jeff Davis