From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Sherwood <john.sherwood.was.taken@gmail.com>
cc: pgsql-sql@postgresql.org
Subject: Re: Backups failing despite many settings that should prevent it
In-reply-to: 
 <CADDayd24gOC5og60a5uMLEyJhZGwMguSgSA0Tv6vfj0kAaGniQ@mail.gmail.com>
References: 
 <CADDayd24gOC5og60a5uMLEyJhZGwMguSgSA0Tv6vfj0kAaGniQ@mail.gmail.com>
Comments: In-reply-to John Sherwood <john.sherwood.was.taken@gmail.com>
 message dated "Tue, 07 Jul 2015 23:35:23 +1000"
Date: Tue, 07 Jul 2015 10:28:30 -0400
Message-ID: <24872.1436279310@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-sql-owner@postgresql.org

John Sherwood <john.sherwood.was.taken@gmail.com> writes:
> I've been getting some backup failures when trying to back up a fairly
> large database.  I've tried setting:

> * vacuum_defer_cleanup_age very high on the master
> * hot_standby_feedback = on on the slave
> * max_standby_streaming_delay = 300s and max_standby_archive_delay = 300s
> on the slave

> Nothing seems to stop it failing intermittently.  The error I'm getting is
> below:
>    pg_dump: Dumping the contents of table "impressions" failed:
> PQgetResult() failed.
>    pg_dump: Error message from server: ERROR:  canceling statement due to
> conflict with recovery
>    DETAIL:  User was holding a relation lock for too long.
>    pg_dump: The command was: COPY public.impressions (id, ... ) TO stdout;
>    The following system errors were returned:
>    Errno::EPERM: Operation not permitted - 'pg_dump' returned exit code: 1

> Any ideas what setting I'm missing?

Sure looks like max_standby_streaming_delay violation from here.  You sure
300s is enough time to back up your "fairly large" database?  How long
does the pg_dump run before failing, anyway?

			regards, tom lane


-- 
Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-sql