Re: ANALYZE locks pg_listener in EXCLUSIVE for long time?
От | Tom Lane |
---|---|
Тема | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? |
Дата | |
Msg-id | 5028.1083560062@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: ANALYZE locks pg_listener in EXCLUSIVE for long (Philip Warner <pjw@rhyme.com.au>) |
Ответы |
Re: ANALYZE locks pg_listener in EXCLUSIVE for long
Re: ANALYZE locks pg_listener in EXCLUSIVE for long |
Список | pgsql-hackers |
Philip Warner <pjw@rhyme.com.au> writes: > At 02:33 PM 3/05/2004, Tom Lane wrote: >> Could you dig a little deeper and see where the problem really is? > I thought I had 8-(. > The result of a 'select * from pg_locks where not granted' was a bunch of > locks on the pg_listener relation, and no others. Only one process had a > lock on that relation, and it was an ANALYZE command. I don't believe any of this. In the first place, if you're not using LISTEN/NOTIFY then there's no reason for any backend to try to take out an AccessExclusive lock on pg_listener (which is the only kind that would be blocked by ANALYZE's measly AccessShareLock). In the second place, an ANALYZE on a zero-page relation cannot conceivably take half an hour, unless it's in turn being blocked by something else. Please dig deeper. regards, tom lane
В списке pgsql-hackers по дате отправления: