Re: pg_dump LOCK TABLE ONLY question

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

In response to

Browse pgsql-hackers by date

  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?