Re: Refactor pg_dump as a library?

On Thu, Apr 14, 2016 at 01:40:21PM -0400, David Steele wrote:
> 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.

I think another issue is that the pg_dump backend gets cache
invalidations from other backends that cause it to reload the cache with
new contents, so even if you pre-loaded the cache at snapshot time, you
would still need to ignore cache invalidations from other backends.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +