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.