Re: Why postgres take RowExclusiveLock on all partition

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why postgres take RowExclusiveLock on all partition
Дата
Msg-id 18017.1474033605@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why postgres take RowExclusiveLock on all partition  (Sachin Kotwal <kotsachin@gmail.com>)
Ответы Re: Why postgres take RowExclusiveLock on all partition  (Sachin Kotwal <kotsachin@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Jeevan Chalke
Дата:
Сообщение: Re: Aggregate Push Down - Performing aggregation on foreign server
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: Vacuum: allow usage of more than 1GB of work mem