| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru>, pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Subject: | Re: SOC & user quotas |
| Date: | 2007-03-01 22:53:08 |
| Message-ID: | 17902.1172789588@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> Is it possible to make the database safe in this case? I can see why it
> would be difficult to handle pg_xlog filling up (or for that matter
> pg_log), but couldn't any other area be turned into just a simple ERROR?
It is --- Josh is mistaken about the severity of the code's response to
out-of-space. We have to panic if out of WAL or CLOG space because we
can't advance the transaction counter anymore in such cases, but
otherwise it's just ERROR. See the archives for some recorded cases of
PG's response to out-of-space situations.
The real problem though is whether you can get anything much done if up
against a hard limit; especially if that limit also affects the system
catalogs. Remember that UPDATE requires the ability to insert new tuple
versions, so there are a whole lot of things that will draw that ERROR.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Saito | 2007-03-01 23:44:56 | Re: Removing some of the old VC++ stuff |
| Previous Message | Jeff Davis | 2007-03-01 22:37:04 | Re: SOC & user quotas |