|From:||Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>|
|Cc:||"'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Joe Conway'" <mail(at)joeconway(dot)com>, "'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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Simon Riggs wrote:
> >Bruce Momjian
> > Simon Riggs wrote:
> > > User-selectable behaviour? OK. That's how we deal with fsync; I can
> > > relate to that. That hadn't been part of my thinking because of the
> > > importance I'd attached to the log files themselves, but I can go
> > > that, if that's what was meant.
> > >
> > > So, if we had a parameter called Wal_archive_policy that has 3
> > > 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 way, we've got something akin to transaction isolation level
> > > various levels of protection.
> > Yep, we will definately need something like that. Basically whenever
> > the logs are being archived, you have to stop the database if you
> > archive, no?
> That certainly was my initial feeling, though I believe it is possible
> to accommodate both viewpoints. I would not want to have only the
> alternative viewpoint, I must confess.
Added to PITR TODO list. Anything else to add:
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
|Next Message||Claudio Natoli||2004-03-09 00:38:39||Re: socket calls in signal handler (WAS: APC + socket r|
|Previous Message||Simon Riggs||2004-03-08 23:28:25||Re: Out of space situation and WAL log pre-allocation (was|