From: | Claire McLister <mclister(at)zeesource(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql general list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Create index hanging |
Date: | 2006-07-21 14:19:16 |
Message-ID: | 83557107-42DE-4BF4-A6DD-3BBE7BA971E2@zeesource.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thanks. I'll look into this next time it happens.
For now, I tried the create index commands again, and they worked in
a split-second. So, it must have been the lock contention, and not
the VACUUM'ng.
On Jul 21, 2006, at 6:45 AM, Tom Lane wrote:
> Claire McLister <mclister(at)zeesource(dot)net> writes:
>> Yes, that could be the case. We have a python function that imports
>> CSV files, which can take a long time, and that may have been running
>> during that time. I didn't look at the pg_lock file. What should I be
>> looking for?
>
> A record with granted = false for the stuck process (joining pid to
> pg_stat_activity will help you determine which process goes with each
> record, or look in "ps" output). If you find one, look for a record
> for the same lock with granted = true and a conflicting lock type;
> that
> tells you which process is blocking the lock.
>
> regards, tom lane
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-07-21 14:25:21 | Re: Column info without executing query |
Previous Message | Csaba Nagy | 2006-07-21 14:14:34 | Re: Create index hanging |