| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Tim Nelson <timnels(at)gmail(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: SELECT and RowExclusiveLock |
| Date: | 2017-04-08 03:04:54 |
| Message-ID: | 14064.1491620694@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tim Nelson <timnels(at)gmail(dot)com> writes:
> New to Postgres and I have never seen this condition. We are getting test
> applications hanging on SELECT statements with a RowExclusiveLock. How can
> a SELECT cause a RowExclusiveLock?
> relname | pid | mode | granted
> --------------------------+-------+------------------+---------
> sales_transaction_detail | 392 | RowExclusiveLock | t
> sales_transaction_detail | 19077 | RowExclusiveLock | t
> sales_transaction_header | 32661 | RowExclusiveLock | t
> sales_transaction_header | 392 | RowExclusiveLock | t
> sales_transaction_header | 19077 | RowExclusiveLock | t
Hm, all those entries are showing granted = t, implying that they are
not blocked. I think you are mis-querying pg_locks or mis-interpreting
the results.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | rob stone | 2017-04-08 03:56:29 | Re: A change in the Debian install |
| Previous Message | Joe Conway | 2017-04-08 02:45:16 | Re: Unable to connect to Postgresql |