From: | Jonathan Bartlett <johnnyb(at)eskimo(dot)com> |
---|---|
To: | Thierry Missimilly <THIERRY(dot)MISSIMILLY(at)BULL(dot)NET> |
Cc: | Relaxin <noname(at)spam(dot)com>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: What is WAL used for? |
Date: | 2003-11-27 13:34:22 |
Message-ID: | Pine.GSU.4.44.0311270533090.22635-100000@eskimo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> Could you tell me what is the real impact of "fsync=false" on the WAL and on the
> database in the same catastrophic scenario ?
I am not certain on this point, but I believe fsync=false messes up the
whole thing. The nice thing about WAL is that fsync is no longer as much
of a slowdown, because PG rarely has to do random-access writes to the
disk.
Jon
>
> Thierry Missimilly
>
> Jonathan Bartlett wrote:
>
> > WAL is write-ahead logging. Basically, before the database actually
> > performs an operation, it writes in a log what it's about to do. Then, it
> > goes and does it. This ensures data consistency. Let's say that the
> > computer was powered off suddenly. There are several points that could
> > happen:
> >
> > 1) before a write - in this case the database would be fine with or
> > without write-ahead logging.
> >
> > 2) during a write - without write-ahead logging, if the machine is powered
> > off during a write, the database has no way of knowing what remained to be
> > written, or what was being written. WIth Postgres, this is furthere
> > broken down into two possibilities:
> >
> > * The power-off occurred while it was writing to the log - in this
> > case, the log is rolled back. The database is unaffected because the data
> > was never written to the database proper.
> >
> > * The power-off occurred after writing to the log, while writing to
> > disk - in this case, Postgres can simply read from the log what was
> > supposed to be written, and complete the write.
> >
> > 3) after a write - again, this does not affect Postgres either with or
> > without WAL.
> >
> > In addition, WAL increases PostgreSQL's efficiency, because it can delay
> > random-access writes to disk, and just do sequential writes to the log for
> > a long time. This reduces the amount of head-seek the dissk are doing.
> > If you store your WAL files on a different disk, you get even more speed
> > advantages.
> >
> > Jon
> >
> > On Tue, 25 Nov 2003, Relaxin wrote:
> >
> > > I'm just trying to figure out the terminology that is used on this board and
> > > wanted to know what is WAL and what roll does it play in Postgresql?
> > >
> > > Thanks
> > >
> > >
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 7: don't forget to increase your free space map settings
> > >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 9: the planner will ignore your desire to choose an index scan if your
> > joining column's datatypes do not match
>
From | Date | Subject | |
---|---|---|---|
Next Message | Doug McNaught | 2003-11-27 13:35:25 | Re: disaster recovery |
Previous Message | Jonathan Bartlett | 2003-11-27 13:28:32 | Re: PostgreSQL, MySQL, etc., was Re: PostgreSQL is much |