Re: Refactor pg_dump as a library? - Mailing list pgsql-hackers

From David Steele
Subject Re: Refactor pg_dump as a library?
Date
Msg-id 570FD343.3080109@pgmasters.net
Whole thread Raw
In response to Re: Refactor pg_dump as a library?  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: Refactor pg_dump as a library?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Refactor pg_dump as a library?  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
On 4/14/16 7:16 AM, Andreas Karlsson wrote:
> On 04/14/2016 12:22 PM, Craig Ringer wrote:
>> I'd find a pg_get_tabledef(...) built-in function more interesting for
>> this particular purpose than pg_dump as a library would be. We already
>> have pg_get_viewdef(...), pg_get_functiondef(...) etc.
> 
> I am personally not a fan of the pg_get_Xdef() functions due to their
> heavy reliance on the syscache which feels rather unsafe in combination
> with concurrent DDL. I would not be surprised if we have some low
> probability bugs which cause inconsistent backups there which just has
> not hit enough people yet to have been reported. And this problem will
> only get worse as we reduce the lock level of more DDL.

As far as I know pg_dump share locks everything before it starts so
there shouldn't be issues with concurrent DDL.  Try creating a new
inherited table with FKs, etc. during a pg_dump and you'll see lots of
fun lock waits.

-- 
-David
david@pgmasters.net



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: has_language_privilege returns incorrect answer for non-superuser
Next
From: Tom Lane
Date:
Subject: Re: Refactor pg_dump as a library?