On Sun, 2 May 2004, Bruce Momjian wrote:
> Tom Lane wrote:
> > Philip Warner <pjw@rhyme.com.au> 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
