From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ANALYZE locks pg_listener in EXCLUSIVE for long time? |
Date: | 2004-05-03 04:54:22 |
Message-ID: | 5028.1083560062@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Philip Warner <pjw(at)rhyme(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2004-05-03 05:05:23 | Re: ANALYZE locks pg_listener in EXCLUSIVE for long |
Previous Message | Philip Warner | 2004-05-03 04:43:14 | Re: ANALYZE locks pg_listener in EXCLUSIVE for long |