Q1 - What is WAL(Write Ahead Log)?

Ans -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.

Q2 - How to deal with pg_xlog out of disk space problem on Postgres ?

Ans - PostgreSQL keeps track of all changes made to the database data files in Write-Ahead Logs (WALs) under the pg_xlog subdirectory of the cluster data directory. You can archive these WALs in a different directory before the database reuses them by copying them to a directory backed up by a network backup tool.
Running out of disk space in the pg_xlog directory is a fairly common Postgres problem. Because of the near write?only nature of this directory, it is often put on a separate disk. Fixing the out of space error is fairly easy.
When the pg_xlog directory fills up and new files cannot be written to it, Postgres will stop running, try to automatically restart, fail to do so, and give up. The pg_xlog directory is so important that Postgres cannot function until there is enough space cleared out to start writing files again. When this problem occurs, the Postgres logs will give you a pretty clear indication of the problem. They will look similar to this:
Remove old WAL files. Check first determine which files are safest to remove. Run pg_controldata and seek "Latest checkpoint's REDO WAL file". It is safe to remove any files older than that one.