Re: [GENERAL] Confused about max_standby_streaming_delay - Mailing list pgsql-general

From Robert Inder
Subject Re: [GENERAL] Confused about max_standby_streaming_delay
Date
Msg-id CAKqjJm8Sr2GvzmH8gJe-ua2E+nK9eXt5TwVo99BLeyvkxkxx1g@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Confused about max_standby_streaming_delay  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: [GENERAL] Confused about max_standby_streaming_delay  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-general


On 6 September 2017 at 20:47, Jeff Janes <jeff.janes@gmail.com> wrote:

Have I misunderstood something?  Or is Postgres not actually configured the way I think it is?

The standby will wait for ten minutes to obtain the lock it wishes to obtain.  In 9.4, if something other than dump of database b was already blocking it for 8 minutes before the dump starts, then the dump of database b will only have 2 minutes, not 10, before it gets cancelled. 

Hmmmm...
You're saying that the time for dumping database b may be spent 8 minutes waiting on a lock then 2 minutes actually dumping.

But would it not still be at least 10 minutes elapsed between the finish time of the previous dump and the following dump starting (let alone finishing)?  And that's what I'm not seeing... 

When one dump fails, there is no 10-minute gap in the mod. times of the other successful dump files....

So, are there any long running jobs in database b other than the pg_dump?
​There shouldn't be.


The standby server is (well, should be!) essentially idle:
 we're using it to do the dumps, so that they don't
 get under the feet of live queries, but ​(I think -- I'll have to check!) that is all
 
 
Cheers,

Jeff

​Robert.​

--
Robert Inder,                                    0131 229 1052 / 07808 492 213
Interactive Information Ltd,   3, Lauriston Gardens, Edinburgh EH3 9HH
Registered in Scotland, Company no. SC 150689
                                           Interactions speak louder than words

pgsql-general by date:

Previous
From: Francisco Olarte
Date:
Subject: Re: [GENERAL] column names query
Next
From: James Sewell
Date:
Subject: [GENERAL] pg_rewind issue