fatal error on 8.1 server

Tony Caduto wrote:

I don't know what the exact version is but I am getting this:

FATAL: database is not accepting commands to avoid wraparound data loss
in database "postgres"

How can I recover from this and why woud this happen to the postgres
database? Has my server been hacked? there should be no inserts or
anything going on.

Stop the postmaster, start a standalone backend, and issue a
database-wide VACUUM on database postgres.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:

Tony Caduto wrote:

I don't know what the exact version is but I am getting this:

FATAL: database is not accepting commands to avoid wraparound data loss
in database "postgres"

How can I recover from this and why woud this happen to the postgres
database? Has my server been hacked? there should be no inserts or
anything going on.

Stop the postmaster, start a standalone backend, and issue a
database-wide VACUUM on database postgres.

Yep, I saw that in the docs, now I am just having problems finding a
standalone backend, not sure what that means.

--
Tony Caduto
AM Software Design
http://www.amsoftwaredesign.com
Home of PG Lightning Admin for Postgresql
Your best bet for Postgresql Administration

On Mon, 2006-11-27 at 13:36 -0600, Tony Caduto wrote:

Alvaro Herrera wrote:

Tony Caduto wrote:

I don't know what the exact version is but I am getting this:

FATAL: database is not accepting commands to avoid wraparound data loss
in database "postgres"

How can I recover from this and why woud this happen to the postgres
database? Has my server been hacked? there should be no inserts or
anything going on.

Stop the postmaster, start a standalone backend, and issue a
database-wide VACUUM on database postgres.

Yep, I saw that in the docs, now I am just having problems finding a
standalone backend, not sure what that means.

postgres.exe or possibly postmaster.exe I don't know how the windows
side does it.

Sincerely,

Joshua D. Drake

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

Alvaro Herrera wrote:

Stop the postmaster, start a standalone backend, and issue a
database-wide VACUUM on database postgres.

Just in case anyone is interested I did get it up and running with no
damage to the system.
It took well over a year for it to reach the 1 million threshold mark.
This is on a very very busy Postfix email server that does lookups
against at table for things like relay hosts etc.
It took awhile for me to piece together everything I needed from the
docs, I found the info about starting a standalone backend in the
reindex docs.

--
Tony Caduto
AM Software Design
http://www.amsoftwaredesign.com
Home of PG Lightning Admin for Postgresql
Your best bet for Postgresql Administration

On Mon, Nov 27, 2006 at 02:22:19PM -0600, Tony Caduto wrote:

Just in case anyone is interested I did get it up and running with no
damage to the system.
It took well over a year for it to reach the 1 million threshold mark.

You mean one *billion*, right?

That's one busy server!

Hopeefully you've updated your maintainence setup to avoid this in the
future?

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/

Martijn van Oosterhout wrote:

On Mon, Nov 27, 2006 at 02:22:19PM -0600, Tony Caduto wrote:

Just in case anyone is interested I did get it up and running with no
damage to the system.
It took well over a year for it to reach the 1 million threshold mark.

You mean one *billion*, right?

That's one busy server!

Hopeefully you've updated your maintainence setup to avoid this in the
future?

Have a nice day,

The server stops accepting requests when it is 1 million transactions
away from hitting 1 billion.
That's what I meant by the 1 million threshold :-)

I did not have autovacuum turned on and I usually do a vacuumdb -z -a -f
-q each night but this one slipped through the cracks :-(

Later,

--
Tony Caduto
AM Software Design
http://www.amsoftwaredesign.com
Home of PG Lightning Admin for Postgresql
Your best bet for Postgresql Administration

Tony Caduto wrote:

Martijn van Oosterhout wrote:

On Mon, Nov 27, 2006 at 02:22:19PM -0600, Tony Caduto wrote:

Just in case anyone is interested I did get it up and running with no
damage to the system.
It took well over a year for it to reach the 1 million threshold mark.

You mean one *billion*, right?

That's one busy server!

Hopeefully you've updated your maintainence setup to avoid this in the
future?

Have a nice day,

The server stops accepting requests when it is 1 million transactions
away from hitting 1 billion.
That's what I meant by the 1 million threshold :-)

I did not have autovacuum turned on and I usually do a vacuumdb -z -a -f
-q each night but this one slipped through the cracks :-(

Strange -- autovacuum should have started an automatic database-wide
vacuum on that database, even if disabled.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera <alvherre@commandprompt.com> writes:

Tony Caduto wrote:

I did not have autovacuum turned on and I usually do a vacuumdb -z -a -f
-q each night but this one slipped through the cracks :-(

Strange -- autovacuum should have started an automatic database-wide
vacuum on that database, even if disabled.

We only added that in 8.2, no? 8.1 autovacuum would have forced the
vacuum to occur, but only if it was enabled in postgresql.conf.

regards, tom lane

Tom Lane wrote:

Alvaro Herrera <alvherre@commandprompt.com> writes:

Tony Caduto wrote:

I did not have autovacuum turned on and I usually do a vacuumdb -z -a -f
-q each night but this one slipped through the cracks :-(

Strange -- autovacuum should have started an automatic database-wide
vacuum on that database, even if disabled.

We only added that in 8.2, no? 8.1 autovacuum would have forced the
vacuum to occur, but only if it was enabled in postgresql.conf.

And in 8.2 it's only a per table vacuum that is required. Is that
correct too?