Re: Why postgres take RowExclusiveLock on all partition - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Why postgres take RowExclusiveLock on all partition
Date
Msg-id 18017.1474033605@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why postgres take RowExclusiveLock on all partition  (Sachin Kotwal <kotsachin@gmail.com>)
Responses Re: Why postgres take RowExclusiveLock on all partition  (Sachin Kotwal <kotsachin@gmail.com>)
List pgsql-hackers
Sachin Kotwal <kotsachin@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



pgsql-hackers by date:

Previous
From: Jeevan Chalke
Date:
Subject: Re: Aggregate Push Down - Performing aggregation on foreign server
Next
From: Pavan Deolasee
Date:
Subject: Re: Vacuum: allow usage of more than 1GB of work mem