Did you connect as the backup user to the db and check what the statement_timeout is from that perspective? It's a locally settable var by db and by user, so it's still possible you'll get bit by this again if it's set for the backup user or just for that db. On Tue, Jan 10, 2012 at 1:13 PM, akp geek <akpgeek@xxxxxxxxx> wrote: > vacuum_cost_delay = 2ms , > I set it as 20ms. last night I did not see any timeouts during the back up. > But I don't understand that. Thanks a lot for the support > > > On Mon, Jan 9, 2012 at 7:17 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> > wrote: >> >> On Mon, Jan 9, 2012 at 1:06 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> >> wrote: >> > On Mon, Jan 9, 2012 at 12:37 PM, akp geek <akpgeek@xxxxxxxxx> wrote: >> >> I have statement_timeout as commented in the postgresql.conf. I just >> >> checked it.. >> > >> > statement timeout, like so many things, can be set per user or per >> > database. Connect as the backup use and issue this statement: >> > >> > show statement_timeout; >> >> The other possibility is that you're getting a network timeout while >> waiting for a response to a select statement. Most network timeouts >> are ~2 hours, but if you've got a firewall look at timeouts. Any >> timeouts should be disabled to troubleshoot. > > -- To understand recursion, one must first understand recursion. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
