> seconds to 10 seconds. The original number was plucked from thin air
> some months ago, and I'd like to review that now based upon further
> thought, observation and experience.
>
> This change has little or no effect on performance, since the interval
> is there mainly to avoid repeated respawn attempts if archiver fails at
> startup. Archiver start-up time is very quick, so there is little danger
> of exceeding 10 seconds.
>
> On a busy system, if the archiver does die, then many files can build up
> in the 60 seconds before respawning. That xlog file backlog could take
> some time to clear. This then leaves a larger than normal window of data
> loss for a possibly long period.
>
> It's a minor change only, with no other effect on function.
Simon Riggs
*
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/postmaster/pgarch.c,v 1.12 2004/11/18 17:13:38 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/postmaster/pgarch.c,v 1.13 2004/12/02 22:40:18 momjian Exp $
*
*-------------------------------------------------------------------------
*/
#define PGARCH_AUTOWAKE_INTERVAL 60 /* How often to force a poll of
* the archive status directory;
* in seconds. */
-#define PGARCH_RESTART_INTERVAL 60 /* How often to attempt to restart
+#define PGARCH_RESTART_INTERVAL 10 /* How often to attempt to restart
* a failed archiver; in seconds. */
/* ----------