Skip site navigation (1) Skip section navigation (2)

Re: SOC & user quotas

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Hiroshi SaitoDate: 2007-03-01 23:44:56
Subject: Re: Removing some of the old VC++ stuff
Previous:From: Jeff DavisDate: 2007-03-01 22:37:04
Subject: Re: SOC & user quotas

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group