Re: Why postgres take RowExclusiveLock on all partition

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

In response to

Responses

Browse pgsql-hackers by date

  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