| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Marko Kreen <markokr(at)gmail(dot)com>, Jeff Amiel <becauseimjeff(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Out of Memory - 8.2.4 |
| Date: | 2007-09-01 02:14:06 |
| Message-ID: | 6118.1188612846@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Also, note that the worst thing that can happen is that the wrong
> process gets a SIGUSR1 signal, and the launcher misses an opportunity
> for starting another worker and rebalancing the vacuum cost parameters.
Hmmm ... okay, but I note that part of that assumption is that every
postgres-owned process either ignores SIGUSR1 or handles it in a fashion
such that an extra signal won't cause any Bad Things. This is not
obvious, especially considering that the Unix default action for SIGUSR1
is abnormal process termination. I'm starting to think that we need a
README somewhere collecting all the system's assumptions about signal
handling.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marco Bizzarri | 2007-09-01 05:58:46 | Re: computing and updating the size of a table with large objects |
| Previous Message | Alvaro Herrera | 2007-09-01 01:53:43 | Re: Out of Memory - 8.2.4 |