I'm honestly not sure what I mean by that -- we didn't write that process. I don't even know the intent of that process; they first told us that it exists yesterday. I'll ask my boss to ask them for more details about it in the morning.
We'll talk with 'em and see if they've done anything weird with the database in the last while.
Thanks for your help.
-Sam
On Thu, Aug 19, 2010 at 5:14 PM, Tom Lane
<tgl@sss.pgh.pa.us> wrote:
Sam Nelson <
samn@consistentstate.com> writes:
>> It's almost certainly not ruby's fault. Have they done anything
>> strange like kill the instance and restart it without letting the db
>> shut down? I'd tend to suspect Amazon's fsyncing is amiss and they
>> did something that triggered it.
> They haven't done anything like that, that we know of. However, they do
> have a process that kills off all waiting (and only waiting) postgres
> processes if there are more than 1000 locks. Could that be an issue?
What do you mean by "kills off"? If they randomly kill -9 backend
processes, I would describe that as taking pot-shots at one's own toes
(and hoping that you can't aim well enough to hit them). In theory
Postgres should survive that without data corruption but it's surely
playing with fire. And it's most definitely not solving whatever their
real problem is.
Anyway, the known issues in this area have to do with the filesystem not
honoring writes in the correct order. I'd agree with Scott's suspicion
that a dirty instance shutdown, rather than a dirty database shutdown,
is the more likely cause.
regards, tom lane
