To re-state the reason behind my posting:
>>[...]
>>I'm trying to use "vacuumdb" as a way to perform a database integrity
>>check before starting my db-enabled application.
>>[...]
>>Now I've made a change and I find myself using the command "vacuumdb
>>-f foo" to perform a full vacuum. However, I've noticed that vacuum
>>full seems to return non-zero return values much more often.
...to which Tom Lane (thank you!) replied:
>This is not a very useful statement. What would be useful is to see the
>error messages you are getting. (Look in the postmaster log, if your
>script is discarding stderr.)
Unfortunately, I don't have the situation repro'd at the very moment.
I will look the next time this happens. However, I do have some other
related questions:
1) Where is the postmaster log kept? I've looked, but I'm cannot seem
to find it.
2) Does a non-zero return value from vacuumdb necessarily mean the
database is corrupted?
3) If vacuumdb returns non-zero, does it mean we should blow away the
database and restore from latest backup? Or is there a typical "fixdb"
application that people run?
4) Are the exit codes in src/bin/pgsql/settings.h the only exit codes
that can be used in the source? Or are there others defined in another
file somewhere else?
5) Is vacuumdb the "right" thing to do for a database integrity check?
6) Is there a better way to do a database integrity check than a
vacuumdb?
And perhaps most importantly,
7) When power fails on a box that is running a 7.2 PostgreSQL database,
do *you* ever find that the database is corrupt when the box comes back
up?
(A few technical details: db version is 7.2; Linux kernel 2.2.14;
postmaster is running with the following command-line:
"/usr/local/pgsql/bin/postmaster -D /foo/data -S"; haven't changed any
of the default tuning values in the p*.conf files.)
Thanks in advance for any assistance you can provide,
Stephane Charette