Re: archivos wal y funcion dumpall

Ok, perdon. Estos son los pasos que segui, de acuerdo con la doc:

Server 1.
1. Ensure that WAL archiving is enabled and working.
2. Connect to the database as a superuser, and issue the command
SELECT pg_start_backup('label');
3. Perform the backup, using any convenient file-system-backup tool
such as tar or cpio. It is neither necessary nor
desirable to stop normal operation of the database while you do this.
4. Again connect to the database as a superuser, and issue the command
SELECT pg_stop_backup();
This should return successfully.
5. Once the WAL segment files used during the backup are archived
as part of normal database activity, you are done.

-Be certain that your backup dump includes all of the files underneath
the database cluster directory (e.g., /usr/local/pgsql/data)
-To make use of this backup, you will need to keep around all the WAL
segment files generated during and after the file system backup.

Server 2.
1 - Stop the postmaster, if it's running.
2 - If you have the space to do so, copy the whole cluster data
directory and any tablespaces to a temporary location in case you need
them later. Note that this precaution will require that you have
enough free space on your system to hold two copies of your existing
database. If you do not have enough space, you need at the least to
copy the contents of the pg_xlog subdirectory of the cluster data
directory, as it may contain logs which were not archived before the
system went down.
3 - Clean out all existing files and subdirectories under the cluster
data directory and under the root directories of any tablespaces you
are using.
4- Restore the database files from your backup dump. Be careful that
they are restored with the right ownership (the database system user,
not root!) and with the right permissions. If you are using
tablespaces, you may want to verify that the symbolic links in
pg_tblspc/ were correctly restored.
5- Remove any files present in pg_xlog/; these came from the backup
dump and are therefore probably obsolete rather than current. If you
didn't archive pg_xlog/ at all, then re-create it, and be sure to
re-create the subdirectory pg_xlog/archive_status/ as well.
6- If you had unarchived WAL segment files that you saved in step 2,
copy them into pg_xlog/. (It is best to copy them, not move them, so
that you still have the unmodified files if a problem occurs and you
have to start over.)
7-Create a recovery command file recovery.conf in the cluster data
directory (see Recovery Settings). You may also want to temporarily
modify pg_hba.conf to prevent ordinary users from connecting until you
are sure the recovery has worked.
8-Start the postmaster. The postmaster will go into recovery mode and
proceed to read through the archived WAL files it needs. Upon
completion of the recovery process, the postmaster will rename
recovery.conf to recovery.done (to prevent accidentally re-entering
recovery mode in case of a crash later) and then commence normal
database operations.

El servidor no arranca y no loggea ningun error (el error de shared
memory fue confusion mia). Al recovery.conf le escribo solo el restore
command..pero igual nunca pasa por ahi.
Hago chown a postgres..y chmod rwx, menos los dir /base y /global que
estan como rw.

Con respecto a mi segunda pregunta, si, corro la funcion dumpall como
root. Lo raro es que desde el query analizer no hay problema. De
cualquier manera lo que estoy buscando es aprender a manejar los
incrementales, mientras tanto me manejo con el dump comun y corriente.

Bueno, eso es todo y no veo bien adonde me equivoco,

gracias