Re: select on 22 GB table causes"An I/O error occured while sending to the backend." exception

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Bill Moran" <wmoran(at)collaborativefusion(dot)com>, "Matthew Wakeling" <matthew(at)flymine(dot)org>
Cc: <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 14:48:21
Message-ID: 48B67465.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

>>> Bill Moran <wmoran(at)collaborativefusion(dot)com> wrote:
> In response to Matthew Wakeling <matthew(at)flymine(dot)org>:
>>
>> Probably the best solution is to just tell the kernel somehow to
never
>> kill the postmaster.
>
> This thread interested me enough to research this a bit.
>
> In linux, it's possible to tell the OOM killer never to consider
> certain processes for the axe, using /proc magic. See this page:
> http://linux-mm.org/OOM_Killer
>
> Perhaps this should be in the PostgreSQL docs somewhere?

That sure sounds like a good idea.

Even though the one time the OOM killer kicked in on one of our
servers, it killed a runaway backend and not the postmaster
( http://archives.postgresql.org/pgsql-bugs/2008-07/msg00105.php ),
I think I will modify our service scripts in /etc/init.d/ to pick off
the postmaster pid after a start and echo -16 (or some such) into the
/proc/<pid>/oom_adj file (which is where I found the file on my SuSE
system).

Thanks for the research and the link!

-Kevin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Steve Atkins 2008-08-28 15:05:37 Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception
Previous Message Bill Moran 2008-08-28 13:53:25 Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception