Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
От | Gavin Sherry |
---|---|
Тема | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? |
Дата | |
Msg-id | Pine.LNX.4.58.0405031411001.3582@linuxworld.com.au обсуждение исходный текст |
Ответ на | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: