On 2014-05-16 18:29:25 +0200, Magnus Hagander wrote:
> On Fri, May 16, 2014 at 6:25 PM, Andres Freund <andres@2ndquadrant.com>wrote:
>
> > On 2014-05-16 18:20:35 +0200, Magnus Hagander wrote:
> > > On Fri, May 16, 2014 at 5:46 PM, Joshua D. Drake <jd@commandprompt.com
> > >wrote:
> > >
> > > > At a minimum:
> > > >
> > > > Check to see if there is going to be a permission error BEFORE the base
> > > > backup begins:
> > > >
> > > > starting basebackup:
> > > > checking perms: ERROR no access to pg_hba.conf~ base backup will fail
> > >
> > >
> > > That's pretty much what it does if you enable progress meter. I realize
> > you
> > > don't necessarily want that one, but we could have a switch that still
> > > tells the server to measure the size, but not actually print the output?
> > > While it costs a bit of overhead to do that, that's certainly something
> > > that's a lot more safe than ignoring errors.
> >
> > Don't think it'll show you that error - that mode only stats() files,
> > right? So you'd need to add access() or open()s.
> >
> >
> You're right, we don't. I thought we did, but was clearly remembering wrong.
>
> I guess we could add an access() call to that codepath though. Not sure if
> that's going to cause any real overhead compared to the rest of what we're
> doing anyway?
It's not free. But I don't think it'd seriously matter in comparison.
But it doesn't protect you if the file is created during the backup -
which as you know can take a long time. For example because somebody
felt the need to increase wal_keep_segments.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services