Re: Refactor pg_dump as a library?

On 4/14/16 1:33 PM, Tom Lane wrote:
> David Steele <david(at)pgmasters(dot)net> writes:
>> On 4/14/16 7:16 AM, Andreas Karlsson wrote:
>>> 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.
>
>> 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.
>
> I think pg_dump is reasonably proof against DDL on tables. It is not
> at all proof against DDL on other sorts of objects, such as functions,
> because of the fact that the syscache will follow catalog updates that
> occur after pg_dump's transaction snapshot.

Hmm, OK. I'll need to go look at that.

I thought that the backend running the pg_dump would fill it's syscache
when it took all the locks and then not update them during the actual
dump. If that's not the case then it's a bit scary, yes.

It seems to make a good case for physical backups vs. logical.

--
-David
david(at)pgmasters(dot)net