Tom Lane wrote:
> Fix LISTEN/NOTIFY race condition reported by Gavin Sherry. While a
> really general fix might be difficult, I believe the only case where
> AtCommit_Notify could see an uncommitted tuple is where the other guy
> has just unlistened and not yet committed. The best solution seems to
> be to just skip updating that tuple, on the assumption that the other
> guy does not want to hear about the notification anyway. This is not
> perfect --- if the other guy rolls back his unlisten instead of committing,
> then he really should have gotten this notify. But to do that, we'd have
> to wait to see if he commits or not, or make UNLISTEN hold exclusive lock
> on pg_listener until commit. Either of these answers is deadlock-prone,
> not to mention horrible for interactive performance. Do it this way
> for now. (What happened to that project to do LISTEN/NOTIFY in memory
> with no table, anyway?)
Added to TODO:
* Allow LISTEN/NOTIFY to store info in memory rather than tables
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
