postgresql VACUUM
-
So I managed to run into the error:
"ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb" HINT: Stop the postmaster and use a standalone backend to vacuum that database. You might also need to commit or roll back old prepared transactions."
I followed google into the solution of restarting the database in standalone mode (like here[^]), but when I run:
VACUUM FULL mytable;
it gives me the message:
backend> VACUUM FULL mytable;
2015-05-06 09:45:09 UTC WARNING: database "mydb" must be vacuumed within 999976 transactions
2015-05-06 09:45:09 UTC HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database.
You might also need to commit or roll back old prepared transactions.
2015-05-06 09:47:53 UTC WARNING: database "mydb" must be vacuumed within 999975 transactions
2015-05-06 09:47:53 UTC HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database.
You might also need to commit or roll back old prepared transactions.
2015-05-06 09:47:53 UTC WARNING: database "mydb" must be vacuumed within 999974 transactions
2015-05-06 09:47:53 UTC HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database.
You might also need to commit or roll back old prepared transactions.
backend>I have no idea what I can do with this.. Just continue the VACUUM for all tables? thanks.
V.
(MQOTD rules and previous solutions)It must be said... that really sucks.
-
It must be said... that really sucks.
That should be marked as abuse!
Never underestimate the power of human stupidity RAH
-
That should be marked as abuse!
Never underestimate the power of human stupidity RAH
That is why I used the joke icon.
-
That should be marked as abuse!
Never underestimate the power of human stupidity RAH
That's all right. I'm a big boy now. Not that the joke is funny, my VACUUM command failed and I'm really worrying right now. This is the development database, but I'm really afraid for the production database following any minute. I did a VACUUM on all tables for production except for one (the largest one) which fails to do anything :sigh:. Anyway, continueing the search, with a positive attitude :)
V.
(MQOTD rules and previous solutions) -
That's all right. I'm a big boy now. Not that the joke is funny, my VACUUM command failed and I'm really worrying right now. This is the development database, but I'm really afraid for the production database following any minute. I did a VACUUM on all tables for production except for one (the largest one) which fails to do anything :sigh:. Anyway, continueing the search, with a positive attitude :)
V.
(MQOTD rules and previous solutions)I meant Tim's response... I can't help as I have zero experience with MySql. You might check out if SQLServerCentral helps out with MySql or if there is a specialist site for the database. This sounds like a DBA level problem not a developer issue.
Never underestimate the power of human stupidity RAH
-
I meant Tim's response... I can't help as I have zero experience with MySql. You might check out if SQLServerCentral helps out with MySql or if there is a specialist site for the database. This sounds like a DBA level problem not a developer issue.
Never underestimate the power of human stupidity RAH
-
Mycroft Holmes wrote:
I meant Tim's response...
I know ... I am the DBA and developer and analyst and tester and ... ;)
V.
(MQOTD rules and previous solutions)V. wrote:
he DBA and developer and analyst and tester and ...
No you are the poor sod having to look after the database, you may have designed, built, populated the data, tuned the indexes and then broke the bloody thing. You are not a DBA, you just have to do that job. Sorry I can't help!
Never underestimate the power of human stupidity RAH
-
That's all right. I'm a big boy now. Not that the joke is funny, my VACUUM command failed and I'm really worrying right now. This is the development database, but I'm really afraid for the production database following any minute. I did a VACUUM on all tables for production except for one (the largest one) which fails to do anything :sigh:. Anyway, continueing the search, with a positive attitude :)
V.
(MQOTD rules and previous solutions)I've never used Postgres or I would help. Can you do a backup and compress? Just grasping for help....
-
So I managed to run into the error:
"ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb" HINT: Stop the postmaster and use a standalone backend to vacuum that database. You might also need to commit or roll back old prepared transactions."
I followed google into the solution of restarting the database in standalone mode (like here[^]), but when I run:
VACUUM FULL mytable;
it gives me the message:
backend> VACUUM FULL mytable;
2015-05-06 09:45:09 UTC WARNING: database "mydb" must be vacuumed within 999976 transactions
2015-05-06 09:45:09 UTC HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database.
You might also need to commit or roll back old prepared transactions.
2015-05-06 09:47:53 UTC WARNING: database "mydb" must be vacuumed within 999975 transactions
2015-05-06 09:47:53 UTC HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database.
You might also need to commit or roll back old prepared transactions.
2015-05-06 09:47:53 UTC WARNING: database "mydb" must be vacuumed within 999974 transactions
2015-05-06 09:47:53 UTC HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database.
You might also need to commit or roll back old prepared transactions.
backend>I have no idea what I can do with this.. Just continue the VACUUM for all tables? thanks.
V.
(MQOTD rules and previous solutions)Again, no Postgres experience, but here is a possible link: http://www.postgresql.org/docs/9.0/static/routine-vacuuming.html[^]
-
Again, no Postgres experience, but here is a possible link: http://www.postgresql.org/docs/9.0/static/routine-vacuuming.html[^]