From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sam Nelson <samn(at)consistentstate(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Memory Errors |
Date: | 2010-09-21 22:50:43 |
Message-ID: | 11111.1285109443@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Sam Nelson <samn(at)consistentstate(dot)com> writes:
> Okay, we're finally getting the last bits of corruption fixed, and I finally
> remembered to ask my boss about the kill script.
> The only details I have are these:
> 1) The script does nothing if there are fewer than 1000 locks on tables in
> the database
> 2) If there are 1000 or more locks, it will grab the processes in
> pg_stat_activity that are in a waiting state
> 3) for each of the previous processes, it will do a system kill $pid call
> The kill is not pg_terminate_backend or pg_cancel_backend, and it's also not
> a kill -9. Just a normal kill.
SIGTERM then. Since (according to the other thread) this was 8.3.11,
that should in theory be safe; but it's not something I'd consider
tremendously well tested before 8.4.x.
I'd still lean to the theory of data lost during an EC2 instance
shutdown.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua J. Kugler | 2010-09-21 23:28:07 | Re: versioned pl/pgsql functions |
Previous Message | Jens Wilke | 2010-09-21 22:10:21 | Re: ERROR: cache lookup failed for type 14237017 |