Bill Moran wrote > How long that takes is a factor of other settings (as David mentioned) and > also depedent on what other transactions may be running. While I am inclined to believe this is true the documentation is unclear that "other transactions" have any bearing on the delay. All the documentation says is that the checkpoint I/O will be spread out over time. Period. I could see where if there is no pending checkpoint I/O to perform that it will return immediately but does having 100MB of I/O to perform, versus 10MB of I/O to perform, cause the delay to increase 9-fold up to a maximum of whatever timeframe is configured? The wording implies that the delay, say 2.5 minutes by default (if I am reading that right), will be used regardless so the system will incur a rate of 4MB/min of checkpoint I/O in the better case and 40MB/min of checkpoint I/O for the worse case. The other possibility is that there is a floor of 10MB/min of checkpoint I/O so the first example only takes 1 minute to return (not 2.5) while the second uses the entire allotted time and also must increase the I/O rate. I'm not sure the precise algorithm needs to be documented but "can take a long time to finish" seems to be taking to the other extreme. Assuming one of the two examples above is correct including such an example in the documentation (i.e., comparing 0MB, 10MB, and 100MB of pending checkpoint I/O) is a thought. Also, is there a way to query how much checkpoint I/O currently is outstanding? If so, and the value is meaningful to this determination, a cross-reference to said information would be useful. Also, assuming the algorithm is fairly constant having it documented at this level, with maybe an example query, would allow people to calculate roughly the amount of time the "false" call will take to return. And yes, I am getting a little carried away here... David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/pg-start-backup-label-true-why-do-I-need-2nd-parameter-tp5777145p5777173.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
