Sachin Kotwal <kotsac...@gmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
