From: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
---|---|
To: | "'Jan Wieck'" <JanWieck(at)Yahoo(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | AW: Re: Idea: recycle WAL segments, don't delete/recrea te 'emm |
Date: | 2001-07-18 08:42:04 |
Message-ID: | 11C1E6749A55D411A9670001FA68796336838A@sdexcsrv1.f000.d0188.sd.spardat.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > > : Most Unix filesystems will not allocate disk blocks until you write in
> > > : them. [...]
> > >
> > > Yes, I understand that, but how is it a problem for postgresql?
> >
> > Uh, I thought we did that so we were not allocating file system blocks
> > during WAL writes. Performance is bad when we do that.
>
> Performance isn't the question.
iirc, at the time, performance was also a question, at least on some of the
platforms that were tested.
> The problem is when you get a
> "disk full" just in the middle of the need to write important
> WAL information. While preallocation of a new WAL file, it's
> OK and controlled, but there are more delicate portions of
> the code.
Of course there should not be, since the write to the WAL is the first IO
:-) Imho all modifying activity could be blocked, until disk space is made
available by the admin. Could you enlighten us on what the delicate portions
are (other than when running in no fsync mode) ?
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Howe | 2001-07-18 08:51:09 | PQexec() 8191 bytes limit and text fields |
Previous Message | Kelbert | 2001-07-18 08:40:57 | ERROR: SELECT DISTINCT ON with postgresql v 7.1.2 |