| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Steele <david(at)pgmasters(dot)net> |
| Cc: | Andreas Karlsson <andreas(at)proxel(dot)se>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Jakob Egger <jakob(at)eggerapps(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Refactor pg_dump as a library? |
| Date: | 2016-04-14 17:33:36 |
| Message-ID: | 1283.1460655216@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Steele | 2016-04-14 17:40:21 | Re: Refactor pg_dump as a library? |
| Previous Message | David Steele | 2016-04-14 17:28:35 | Re: Refactor pg_dump as a library? |