On Sun, 2 May 2004, Bruce Momjian wrote: > Tom Lane wrote: > > Philip Warner <[EMAIL PROTECTED]> writes: > > > Does this mean that ANALYZE will take an exclusive lock on pg_listener > > > until the ANALYZE finishes? Or is there some other cause? > > > > ANALYZE does not take an exclusive lock on anything. However, the > > async.c functions want AccessExclusiveLock on pg_listener, so they > > quite possibly would get blocked by ANALYZE's not-so-exclusive lock. > > > > Possibly we could reduce the strength of the lock taken by the async.c > > functions ... I haven't thought hard about it. The long-term answer is > > certainly a wholesale rewrite of the listen/notify mechanism. > > Gavin was working on it a while ago but I am not sure how far he got.
Its basically written. It is implemented using shared memory. I got stuck when I considered the situation where we rung out of shared memory. Some emails in the archive suggested we just fire all listeners but I didn't like that. What I was considering was that when someone issues a NOTIFY, we reserve a slot for the NOTIFY (plus a message, which is why I originally looked at the problem) in shared memory. At the end of the transaction, we update a flag to say that the transaction successed or we remove it if we've aborted. Does anyone else have any thoughts about it? Gavin ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org