Обсуждение: Postgres 7.4.2 hanging when vacuum full is run
Hi -
This has been happening more recently. Our database hangs after a VACUUM and is unresponsive when we come in next morning.
The vacuum job runs at 03:00 am daily.
The command is : /usr/local/pgsql/bin/vacuumdb --full -d DbName
Also, what exactly does this mean VACUUM waiting. Is there a reason why it is never emerging from the VACUUM job?
I understand that doing a vacuumdb --full causes the tables to lock (not really sure about the workings of vacuum).
Any light on this would be really appreciated.
Thanks,
Radhika
Below is what ps -ef |grep postgres shows:
5530 ? S 0:13 /usr/local/pgsql/bin/postmaster -i
5534 ? S 0:01 postgres: stats buffer process
5535 ? S 0:04 postgres: stats collector process
5621 ? S 0:53 postgres: slony myDB 10.142.20.50 idle
5626 ? S 0:51 postgres: slony myDB 10.142.20.50 idle
5627 ? S 0:34 postgres: slony myDB 10.142.20.50 idle
5628 ? S 5:40 postgres: slony myDB 10.142.20.50 idle
5637 ? S 2:09 postgres: slony myDB 10.132.20.26 idle
5638 ? S 1:56 postgres: slony myDB 10.132.20.26 idle
5745 ? S 42:08 postgres: abc myDB [local] idle
20774 ? S 4:29 postgres: abc myDB [local] idle
20775 ? S 0:00 postgres: abc myDB [local] idle in transaction
20776 ? S 0:00 postgres: abc myDB [local] idle
17509 ? S 0:06 postgres: abc myDB [local] VACUUM waiting
24656 ? S 0:00 postgres: abc myDB [local] INSERT waiting
30489 ? S 0:00 postgres: abc myDB [local] SELECT waiting
30637 ? S 0:00 postgres: abc myDB [local] UPDATE waiting
30647 ? S 0:00 postgres: abc myDB [local] UPDATE waiting
30668 ? S 0:00 postgres: abc myDB [local] UPDATE waiting
--
It is all a matter of perspective. You choose your view by choosing where to stand. --Larry Wall
This has been happening more recently. Our database hangs after a VACUUM and is unresponsive when we come in next morning.
The vacuum job runs at 03:00 am daily.
The command is : /usr/local/pgsql/bin/vacuumdb --full -d DbName
Also, what exactly does this mean VACUUM waiting. Is there a reason why it is never emerging from the VACUUM job?
I understand that doing a vacuumdb --full causes the tables to lock (not really sure about the workings of vacuum).
Any light on this would be really appreciated.
Thanks,
Radhika
Below is what ps -ef |grep postgres shows:
5530 ? S 0:13 /usr/local/pgsql/bin/postmaster -i
5534 ? S 0:01 postgres: stats buffer process
5535 ? S 0:04 postgres: stats collector process
5621 ? S 0:53 postgres: slony myDB 10.142.20.50 idle
5626 ? S 0:51 postgres: slony myDB 10.142.20.50 idle
5627 ? S 0:34 postgres: slony myDB 10.142.20.50 idle
5628 ? S 5:40 postgres: slony myDB 10.142.20.50 idle
5637 ? S 2:09 postgres: slony myDB 10.132.20.26 idle
5638 ? S 1:56 postgres: slony myDB 10.132.20.26 idle
5745 ? S 42:08 postgres: abc myDB [local] idle
20774 ? S 4:29 postgres: abc myDB [local] idle
20775 ? S 0:00 postgres: abc myDB [local] idle in transaction
20776 ? S 0:00 postgres: abc myDB [local] idle
17509 ? S 0:06 postgres: abc myDB [local] VACUUM waiting
24656 ? S 0:00 postgres: abc myDB [local] INSERT waiting
30489 ? S 0:00 postgres: abc myDB [local] SELECT waiting
30637 ? S 0:00 postgres: abc myDB [local] UPDATE waiting
30647 ? S 0:00 postgres: abc myDB [local] UPDATE waiting
30668 ? S 0:00 postgres: abc myDB [local] UPDATE waiting
--
It is all a matter of perspective. You choose your view by choosing where to stand. --Larry Wall
On Sep 28, 2007, at 10:28 AM, Radhika S wrote:
20775 ? S 0:00 postgres: abc myDB [local] idle in transaction
20776 ? S 0:00 postgres: abc myDB [local] idle
17509 ? S 0:06 postgres: abc myDB [local] VACUUM waiting
24656 ? S 0:00 postgres: abc myDB [local] INSERT waiting
You're vacuum is probably waiting for the "idle in transaction" session to finish, so it can clean up. It can't take a lock if your transaction has locks. Your other tasks are probably waiting behind the vacuum. Don't leave your transactions open for a long time. it is bad.
On top of what Vivek said, you need to update your pg install. 7.4.2 had a few data eating bugs if I remember correctly. 7.4 branch is up to 7.4.18, and those are a lot of bug fixes (2+ years) you're missing. If one of those bugs eats your data, don't expect any sympathy.