| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | david(at)lang(dot)hm, Andrew Sullivan <ajs(at)commandprompt(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception |
| Date: | 2008-08-28 04:35:07 |
| Message-ID: | 357.1219898107@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Some time ago I found that it was possible to fiddle with a /proc entry
> to convince the OOM to not touch the postmaster. A postmaster with the
> raw IO capability bit set would be skipped by the OOM too killer (this
> is an Oracle tweak AFAIK).
> These are tricks that people could use in their init scripts to protect
> themselves.
Yeah? Details please? Does the bit get inherited by child processes?
> (I wonder if the initscript supplied by the RPMs or Debian should
> contain such a hack.)
It would certainly make sense for my RHEL/Fedora-specific packages,
since those are targeting a very limited range of kernel versions.
Not sure about the situation for other distros.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-08-28 04:56:23 | Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception |
| Previous Message | Alvaro Herrera | 2008-08-28 02:19:52 | Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception |