| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
| Cc: | Matthew Dennis <mdennis(at)merfer(dot)net>, david(at)lang(dot)hm, Matthew Wakeling <matthew(at)flymine(dot)org>, PostgreSQL Performance <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-29 02:32:18 |
| Message-ID: | 20080829023218.GK8424@alvh.no-ip.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Scott Marlowe escribió:
> scenario 1: There's a postmaster, it owns all the child processes.
> It gets killed. The Postmaster gets restarted. Since there isn't one
> running, it comes up.
Actually there's an additional step required at this point. There isn't
a postmaster running, but a new one refuses to start, because the shmem
segment is in use. In order for the second postmaster to start, the
sysadmin must remove the PID file by hand.
> starts new child processes. Meanwhile, the old child processes that
> don't belong to it are busy writing to the data store. Instant
> corruption.
In this scenario, it is both a kernel fault and sysadmin stupidity. The
corruption that ensues is 100% deserved.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | david | 2008-08-29 02:42:02 | Re: select on 22 GB table causes "An I/O error occured while sending to the backend." exception |
| Previous Message | Greg Smith | 2008-08-29 02:29:45 | Re: Postgres not using array |