Thread: Please humor me ...

And by the subject, I mean:  please provide a "factual" answer, as opposed
to the more or less obvious answer which would be "no one in their sane
mind would even consider doing such thing"  :-)

1) Would it be possible to entirely disable WAL?  (something like setting a
symlink so that pg_xlog points to /dev/null, perhaps?)

2) What would be the real implications of doing that?

As I understand it, the WAL provide some sort of redundancy for fault-
tolerance purposes;  if my understanding is correct, then what kind of
data loss are we talking about if I entirely disabled WAL and the machine
running the DB cluster were to crash/freeze?  What about a physical
reboot (either a UPSless power-down, or someone pressing the reset
button)?  Or are we talking about the entire DB cluster possibly
becoming corrupt beyond repair with 0% of the data being recoverable?


Again, please bear with me ...  I do know and understand the "no one in
their sane mind would even consider doing such thing"  aspect ...  I'm
for now interested in knowing more in detail the real facts behind this
feature --- allow me to think outside the box for a little while  :-)


Thanks,

Carlos
--

On Mon, 2007-04-09 at 16:05 -0400, Carlos Moreno wrote:
> And by the subject, I mean:  please provide a "factual" answer, as opposed
> to the more or less obvious answer which would be "no one in their sane
> mind would even consider doing such thing"  :-)
>
> 1) Would it be possible to entirely disable WAL?  (something like setting a
> symlink so that pg_xlog points to /dev/null, perhaps?)

You can't disable WAL, but you can disable fsync.

> 2) What would be the real implications of doing that?
>

A good chance that you lose your entire database cluster if the power
fails.

It's not just your tables that require WAL, it's also the system
catalogs. If you were to disable it, and a system catalog became
corrupt, the database would not know what to do.

There's always a chance you could recover some of that data by a manual
process (i.e. open up the database files in a hex editor and look for
your data), but there would be no guarantee.

Regards,
    Jeff Davis

On Mon, 2007-04-09 at 16:05 -0400, Carlos Moreno wrote:
> 2) What would be the real implications of doing that?

Many people ask, hence why a whole chapter of the manual is devoted to
this important topic.

http://developer.postgresql.org/pgdocs/postgres/wal.html

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com