From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Woodward <pgsql(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PostgreSQL 8.0.6 crash |
Date: | 2006-02-09 19:31:48 |
Message-ID: | 87k6c472hn.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> Unless I've missed something here, disabling the OOM killer doesn't
> really solve the problem here.
Well in a way it does. Postgres would get an out-of-memory error from malloc
which it would handle properly and the world would be happy.
Except not quite, since I think an out of memory error still means that
backend exits instead of just that query failing. That means if you have an
application running such as apache then all subsequent transactions on that
connection fail too, instead of just the transaction that misbehaved.
And as the other poster mentioned, having Postgres use up every available byte
of memory isn't really very friendly to anything else running on the box.
It doesn't seem like a bad idea to have a max_memory parameter that if a
backend ever exceeded it would immediately abort the current transaction. That
would let an application continue operating normally after getting an error.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-02-09 19:35:34 | Re: PostgreSQL 8.0.6 crash |
Previous Message | Joachim Wieland | 2006-02-09 19:31:07 | Re: [GENERAL] Sequences/defaults and pg_dump |