Re: Listen / Notify - what to do when the queue is full - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Listen / Notify - what to do when the queue is full
Date
Msg-id 1263944489.13109.27.camel@monkey-cat.sm.truviso.com
Whole thread Raw
In response to Re: Listen / Notify - what to do when the queue is full  (Joachim Wieland <joe@mcknight.de>)
Responses Re: Listen / Notify - what to do when the queue is full  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: lock_timeout GUC patch
Next
From: Robert Haas
Date:
Subject: Re: lock_timeout GUC patch