AW: Re: Idea: recycle WAL segments, don't delete/recrea te 'emm - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: Re: Idea: recycle WAL segments, don't delete/recrea te 'emm
Date
Msg-id 11C1E6749A55D411A9670001FA68796336838A@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
List 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


pgsql-hackers by date:

Previous
From: jerome crouigneau
Date:
Subject: Memory management
Next
From: Jean-Michel Kelbert
Date:
Subject: ERROR: SELECT DISTINCT ON with postgresql v 7.1.2