AW: Re: Idea: recycle WAL segments, don't delete/recrea te 'emm

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

Browse pgsql-hackers by date

  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