From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sachin Kotwal <kotsachin(at)gmail(dot)com> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why postgres take RowExclusiveLock on all partition |
Date: | 2016-09-16 13:46:45 |
Message-ID: | 18017.1474033605@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Sachin Kotwal <kotsachin(at)gmail(dot)com> writes:
> In another Terminal :
> postgres=# select locktype, database::regclass ,
> relation::regclass,virtualtransaction, pid, mode , granted from pg_locks
> where locktype='relation';
> locktype | database | relation | virtualtransaction | pid | mode
> | granted
> ----------+----------+----------+--------------------+-------+------------------+---------
> relation | 13241 | pg_locks | 3/3867 | 28635 |
> AccessShareLock | t
> relation | 13241 | t1_p2 | 2/14038 | 28633 |
> RowExclusiveLock | t
> relation | 13241 | t1_p1 | 2/14038 | 28633 |
> RowExclusiveLock | t
> relation | 13241 | t1 | 2/14038 | 28633 |
> RowExclusiveLock | t
> (4 rows)
The planner must take some type of lock on each partition, because it
has to examine that table and decide whether or not it needs to be
scanned, and that at least requires locking the table's DDL state.
So those locks will be there whether or not the query ultimately scans
the tables. This isn't a bug.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2016-09-16 13:47:14 | Re: Vacuum: allow usage of more than 1GB of work mem |
Previous Message | Jeevan Chalke | 2016-09-16 13:45:33 | Re: Aggregate Push Down - Performing aggregation on foreign server |