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

From Sachin Kotwal
Subject Re: Why postgres take RowExclusiveLock on all partition
Date
Msg-id CA+N_YAer1Nc3mTUurQR+4wB842VpT6QvedUwud5vQctafMDBDQ@mail.gmail.com
Whole thread Raw
In response to Re: Why postgres take RowExclusiveLock on all partition  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why postgres take RowExclusiveLock on all partition
List pgsql-hackers
Hi Tom,


Thanks for reply.

To take decision it should get locks for very small interval.
Does it release locks after taking decision and then perform actual update operation on partition table?
I feel update operation can take longer time than planner to examine and will not require lock in later stage of query execution.

Locking all partition tables leads to blocking all queries(mostly select * ... kind of)  who want lock on other partition.
If we able to release lock immediately  after planner examination it will help to get locks to other running queries on other partitions.

If will be happy we will be able to reduce locking in above scenario.


Regards,
Sachin

On Fri, Sep 16, 2016 at 7:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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



--

Thanks and Regards,
Sachin Kotwal

pgsql-hackers by date:

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