David Mitchell <david.mitchell@xxxxxxxxxxx> writes:
> Hi,
>
> We're running a Postgres 8.0.1 database and have a maintenance process
> that runs vacuum on selected tables every 10 minutes. Each table takes
> around 2-3 seconds to vacuum. Since we've started this process we've
> seen a lot of postmaster crashes (it says it received signal 9). It
> appears these crashes occur when we try to stop a vacuum by
> interrupting the vacuumdb process, but sometimes they occur without us
> having to do this.
>
> Any ideas? We didn't experience so many database crashes before we
> started vacuuming regularly.
If you're running Linux, it's possible that your system is
overcommitted and low on memory and the kernel is picking random
processes to kill. There should be entries in the syslogs related to
this, if that's what's happening. There are ways to tell (some
versions of) Linux not to overcommit memory.
Otherwise, no part of Postgres sends signal 9 AFAIK, so it's either a
rogue script or a person doing the killing.
-Doug
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
