|
1 | 1 | <!-- |
2 | | -$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.7 2001/11/18 22:17:30 tgl Exp $ |
| 2 | +$Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.8 2001/11/20 04:27:49 tgl Exp $ |
3 | 3 | --> |
4 | 4 |
|
5 | 5 | <chapter id="maintenance"> |
@@ -34,10 +34,8 @@ $Header: /cvsroot/pgsql/doc/src/sgml/maintenance.sgml,v 1.7 2001/11/18 22:17:30 |
34 | 34 | </para> |
35 | 35 |
|
36 | 36 | <para> |
37 | | - It is also necessary to rotate the database server log file that is specified |
38 | | - when the <application>postmaster</application> is started. If you are using |
39 | | - <application>syslog</application>, you can send a <literal>SIGHUP</literal> |
40 | | - signal to the syslog daemon to force it to start writing a new log file. |
| 37 | + Something else that might need periodic attention is log file management. |
| 38 | + This is discussed in <xref linkend="logfile-maintenance">. |
41 | 39 | </para> |
42 | 40 |
|
43 | 41 | <para> |
@@ -367,6 +365,61 @@ VACUUM |
367 | 365 |
|
368 | 366 | </sect2> |
369 | 367 | </sect1> |
| 368 | + |
| 369 | + <sect1 id="logfile-maintenance"> |
| 370 | + <title>Log File Maintenance</title> |
| 371 | + |
| 372 | + <indexterm zone="logfile-maintenance"> |
| 373 | + <primary>log files</primary> |
| 374 | + </indexterm> |
| 375 | + |
| 376 | + <para> |
| 377 | + It's a good idea to save the database server's log output somewhere, |
| 378 | + rather than just routing it to <filename>/dev/null</>. The log output |
| 379 | + is invaluable when it comes time to diagnose problems. However, the |
| 380 | + log output tends to be voluminuous (especially at higher debug levels) |
| 381 | + and you won't want to save it indefinitely. You need to <quote>rotate</> |
| 382 | + the log files so that new log files are started and old ones thrown |
| 383 | + away every so often. |
| 384 | + </para> |
| 385 | + |
| 386 | + <para> |
| 387 | + If you simply direct the postmaster's stderr into a file, the only way |
| 388 | + to truncate the log file is to stop and restart the postmaster. This |
| 389 | + may be okay for development setups but you won't want to run a production |
| 390 | + server that way. |
| 391 | + </para> |
| 392 | + |
| 393 | + <para> |
| 394 | + The simplest production-grade approach to managing log output is to send it |
| 395 | + all to <application>syslog</> and let <application>syslog</> deal with file |
| 396 | + rotation. To do this, make sure <productname>Postgres</> was built with |
| 397 | + the <option>--enable-syslog</> configure option, and set |
| 398 | + <literal>syslog</> to 2 |
| 399 | + (log to syslog only) in <filename>postgresql.conf</>. |
| 400 | + Then you can send a <literal>SIGHUP</literal> signal to the |
| 401 | + <application>syslog</> daemon whenever you want to force it to start |
| 402 | + writing a new log file. |
| 403 | + </para> |
| 404 | + |
| 405 | + <para> |
| 406 | + On many systems, however, syslog is not very reliable, particularly |
| 407 | + with large log messages; it may truncate or drop messages just when |
| 408 | + you need them the most. You may find it more useful to pipe the |
| 409 | + <application>postmaster</>'s stderr to some type of log rotation script. |
| 410 | + If you start the postmaster with <application>pg_ctl</>, then the |
| 411 | + postmaster's stderr is already redirected to stdout, so you just need a |
| 412 | + pipe command: |
| 413 | + |
| 414 | +<screen> |
| 415 | +<userinput>pg_ctl start | logrotate</userinput> |
| 416 | +</screen> |
| 417 | + |
| 418 | + The <productname>Postgres</> distribution doesn't include a suitable |
| 419 | + log rotation program, but there are many available on the net; |
| 420 | + one is included in the Apache distribution, for example. |
| 421 | + </para> |
| 422 | + </sect1> |
370 | 423 | </chapter> |
371 | 424 |
|
372 | 425 | <!-- Keep this comment at the end of the file |
|