Database Administration - PostgreSQL: Up and Running - page 43

Verboten Practices
We have been witness to many ways that people have managed to break their PostgreSQL
server, so we thought it best to end this chapter by itemizing the most common mistakes.
For starters, if you don't know what you did wrong, the log file could provide clues.
Look for the pg_log folder in your PostgreSQL data folder or the root of the PostgreSQL
data folder for the log files. It's also possible that your server shut down before a log
entry could be written, in which case the log won't help you. If your server fails to restart,
try the following from the OS command line:
path/to/your/bin/ pg_ctl -D your_postgresql_data_folder
Don't Delete PostgreSQL Core System Files and Binaries
Perhaps this is stating the obvious, but when people run out of disk space, the first thing
they do is panic and start deleting files from the PostgreSQL data cluster folder because
it's so darn big. Part of the reason this mistake happens so frequently is that some folders
names such as pg_log , pg_xlog , and pg_clog sound like folders for logs that you expect
to build up and be safe to delete. There are some files you can safely delete and some
that will destroy your data if you do.
The pg_log folder, often found in your data folder, is a folder that builds up quickly,
especially if you have logging enabled. You can always purge files from this folder
without harm. In fact, many people schedule jobs to remove log files on a regular basis.
Files in the other folders, except for pg_xlog , should never be deleted, even if they have
log-sounding names. Don't even think of touching pg_clog , the active commit log.
pg_xlog stores transaction logs. Some systems we've seen are configured to move pro‐
cessed transaction logs into a subfolder called archive . You'll often have an archive folder
somewhere (not necessarily as a subfolder of pg_xlog ) if you are running synchronous
replication, doing continuous archiving, or just keeping logs around in case you need
to revert to a different point in time. Deleting files in the root of pg_xlog will destroy
data. Deleting files in the archived folder will just prevent you from performing point-
in-time recovery, or if a slave server hasn't played back the logs, will prevent the slave
from fetching them. If these scenarios don't apply to you, it's safe to delete or move files
in the archive folder.
Be leery of overzealous antivirus programs, especially on Windows. We've seen cases in
which antivirus software removed important binaries in the PostgreSQL bin folder. If
PostgreSQL fails to start on a Windows system, the event viewer is the first place to look
for clues as to why.