From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | simon(at)2ndquadrant(dot)com |
Cc: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 'Gavin Sherry' <swm(at)linuxworld(dot)com(dot)au>, tswan(at)idigx(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Out of space situation and WAL log pre-allocation (was |
Date: | 2004-03-03 21:52:06 |
Message-ID: | 40465386.7030204@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs wrote:
>> Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us] That should be user-scriptable
>> policy, in my worldview.
> O... and other dbms will freeze when this situation is hit, rather
> than continue and drop archive logs.]
Been there, done that, don't see how it's any better. I hesitate to be
real specific here, but let's just say the end result was restore from
backup :-(
> So, if we had a parameter called Wal_archive_policy that has 3
> settings: None = no archiving Optimistic = archive, but if for some
> reason log space runs out then make space by dropping the oldest
> archive logs Strict = if log space runs out, stop further write
> transactions from committing, by whatever means, even if this takes
> down dbms.
That sounds good to me. For the "Optimistic" case, we need to yell
loudly if we do find ourselves needing to drop segments. For the
"Strict" case, we just need to be sure it works correctly ;-)
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2004-03-03 21:57:28 | Slony-I makes progress |
Previous Message | Bill Moran | 2004-03-03 21:42:34 | Shouldn't B'1' = 1::bit be true? |