Sam Nelson <samn@xxxxxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
