Re: pg_dump LOCK TABLE ONLY question - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_dump LOCK TABLE ONLY question
Date
Msg-id CAB7nPqR9ePT0Qx0BtW_j7WDRJvTkrDwfu32YkTvw7bCxBmnWmQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_dump LOCK TABLE ONLY question  (Noah Misch <noah@leadboat.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: Some 9.5beta2 backend processes not terminating properly?
Next
From: Michael Paquier
Date:
Subject: Release notes of 9.0~9.3 mentioning recovery_min_apply_delay incorrectly