Re: pg_dump LOCK TABLE ONLY question

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_dump LOCK TABLE ONLY question
Дата
Msg-id CAB7nPqR9ePT0Qx0BtW_j7WDRJvTkrDwfu32YkTvw7bCxBmnWmQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_dump LOCK TABLE ONLY question  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Sat, Jan 2, 2016 at 12:28 PM, Noah Misch <noah@leadboat.com> wrote:
> On Sat, Oct 31, 2015 at 10:14:18AM +0100, Simon Riggs wrote:
>> I agree with Filip that this is a bug. pg_dump clearly doesn't work
>> correctly with inheritance.
>>
>> If I run this command
>>
>>   pg_dump -t tab1
>>
>> then I get a dump of "tab1".  No data is included from tables that inherit
>> tab1 because COPY refers only to the target table.
>>
>> Why should that action cause a lock to be taken on another table that
>> inherits from tab1?
>>
>> It seems clear that the user is requesting an action ONLY on tab1, so we
>> should use LOCK TABLE tab1 ONLY;
>
> +1

Hm. Looking one extra time at that, the patch upthread should as well
do the same for the parallel mode introduced in 9.3 as data is always
bumped using FROM ONLY. See for example the attached..
--
Michael

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Some 9.5beta2 backend processes not terminating properly?
Следующее
От: Michael Paquier
Дата:
Сообщение: Release notes of 9.0~9.3 mentioning recovery_min_apply_delay incorrectly