On 2014-05-16 18:29:25 +0200, Magnus Hagander wrote: > On Fri, May 16, 2014 at 6:25 PM, Andres Freund <and...@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 <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers