General PostgreSQL administration question:
I'm trying to use "vacuumdb" as a way to perform a database integrity
check before starting my db-enabled application. I used to run it as
"vacuumdb foo" and if the return code was anything other than zero, I
knew the database was most likely hosed. (A
"Stephane Charette" <[EMAIL PROTECTED]> writes:
> 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.
This is not a very useful statement. What wo
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,
"Stephane Charette" <[EMAIL PROTECTED]> writes:
> 1) Where is the postmaster log kept? I've looked, but I'm cannot seem
> to find it.
I'm talking about the postmaster's stderr output. Look to see what your
postmaster startup script does with stderr ... if it routes it to
/dev/null, you'll need t
Tom Lane wrote:
>IIRC, there were some problems with sequences going backwards after a
>crash in 7.2. If you are on 7.2.x for x < 3, you are running a version
>with serious known bugs; you should update before complaining too much
>...
Crazy question, but how do I determine the version number?
"Stephane Charette" <[EMAIL PROTECTED]> writes:
> If I run "postmaster --version", I get told "postmaster (PostgreSQL)
> 7.2".
> Does that really mean "7.2"?
Yes, it does. You could double-check with "select version()" though.
regards, tom lane
-
Our client is running a large-ish database, and has infrequently been
getting the following messages:
Nov 6 04:17:09 dolidb-n1 logger: NOTICE: Rel pg_type: Uninitialized
page 6 - fixing
Nov 6 04:17:09 dolidb-n1 logger: NOTICE: Rel pg_type: Uninitialized
page 7 - fixing
Nov 6 04:17:09 dolidb-n
>> 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.
>
>This is not a very useful statement. What would be useful is to see the
>error messages
"Stephane Charette" <[EMAIL PROTECTED]> writes:
> The error received when we run "vacuumdb" is:
> -> ERROR: Cannot insert a duplicate key into unique index
> pg_class_oid_index
That's pretty interesting. My first thought is a corrupt index.
Please try reindexing pg_class. You'll need to do thi
