Recent OSDL test reports for 8.0RC1 show that checkpoints occur too frequently for higher settings of checkpoint_segments and checkpoint_timeout. This is incorrect according to the manual, and the intention of the current implementation from examining the code.
Early tests showed that checkpoints were occurring too frequently. checkpoint_timeout was set to 600 and 1800, on two separate tests, yet checkpoints occurred in around 6m 15s. checkpoint_segments was set to 8192 for the last test, yet checkpoints did not occur any less frequently. The presence of manual CHECKPOINTs has been ruled out by the test author, Mark Wong. DEBUG1 messages showed that there is an apparent limit of 255 xlog files per checkpoint - this cannot be just a reporting bug since the checkpoint timings are simply not increasing as requested by the parameter settings. Many checkpoints occur with a spread of values from 0..255, though in one run there are 18 consecutive checkpoints with exactly 255 files. Across the whole test there were 48 checkpoints, of which 25 checkpoints recycled exactly 255 files and all others recycled less. This situation could occur by chance, but with an extremely low probability, which I estimate to be of at least of the order of 1 in 1 million - even a single test result higher than 255 would disprove this, but none are available (anyone?). Results referred to above are shown here: http://www.osdl.org/projects/dbt2dev/results/dev4-010/207/db/log checkpoint_segments is limited to the range 0..INT_MAX in the code, so should not be limited to only 255 files, which dare I say is suspiciously 1 bytes worth of files. Not only is this a bug, but it limits high-end performance for those who would wish to set those parameters higher. Brief examination of the code reveals no explanation for this observation, so I'm raising it for general investigation. Happy for someone to explain how to make checkpoints occur less frequently... (apart from don't write to the database). -- Best Regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
