From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump LOCK TABLE ONLY question |
Date: | 2016-01-02 12:02:42 |
Message-ID: | CAB7nPqR9ePT0Qx0BtW_j7WDRJvTkrDwfu32YkTvw7bCxBmnWmQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 2, 2016 at 12:28 PM, Noah Misch <noah(at)leadboat(dot)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 | Content-Type | Size |
---|---|---|
20160102_pg_dump_lock.patch | text/x-patch | 2.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-01-02 12:21:14 | Release notes of 9.0~9.3 mentioning recovery_min_apply_delay incorrectly |
Previous Message | Petr Jelinek | 2016-01-02 11:32:53 | Re: Some 9.5beta2 backend processes not terminating properly? |