| From: | Michael Fuhr <mike(at)fuhr(dot)org> |
|---|---|
| To: | Sriram Dandapani <sdandapani(at)counterpane(dot)com> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: determining which operation is blocking another query |
| Date: | 2006-05-25 07:27:07 |
| Message-ID: | 20060525072707.GA31892@winnie.fuhr.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Wed, May 24, 2006 at 11:49:37PM -0700, Sriram Dandapani wrote:
> Is there a system view that can be used to determine which
> INSERT/UPDATE/DELETE/Other Operation is blocking a SELECT statement.
Query pg_locks to see what locks transactions have acquired or are
waiting to acquire. If you have stats_command_string enabled then
querying pg_stat_activity should show sessions' current queries.
Are you sure SELECT is blocked, or could it just be taking a long
time? MVCC allows SELECT to run concurrently with INSERT, UPDATE,
and DELETE without blocking; only a few operations like VACUUM FULL
block an ordinary SELECT (without FOR SHARE or FOR UPDATE).
--
Michael Fuhr
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Adam Radlowski | 2006-05-25 10:59:14 | Re: defining Your own sort order for already compiled PostgreSQL |
| Previous Message | Sriram Dandapani | 2006-05-25 06:49:37 | determining which operation is blocking another query |