Thread: Need help on WAL configure

Need some help to configure the WAl files shipping and restore it to the target server.here is what I configured in the
sourceserver. (both windows)In postgresql.conf, I enabled the following option.# WRITE AHEAD LOGfsync = on           
   synchronous_commit= on      wal_sync_method = fsync   # - Archiving -archive_mode = onarchive_command = 'copy "%p"
"D:\\PG_DATA\\%f"'   #archive_timeout= 0   D drive is on the same source server ( I am also having trouble to ship it
totarget, had a network drive mapped in the source server, for some reason I couldn't get it copy over to this network
drive,so had to copy it local D drive first).created the checkpoint, then make the base backup and copy the backup file
totarget along with archived WAL files. (filename: 0000000100000.... etc)Next step is to restore the base backup in the
targetserver,after restore the base backup, stop PG service, then move away any file (filename: 0000200000000... etc)
underpg_xlog, and copy source's WAL files to pg_xlogcreate recovery.conf file with the following line.restore_command =
'copy"C:\\pgwal\\%f" "%p"'when I tried to start PG service, for some reason, the recovery command is always looking for
0000200000000,which was created during the base backup restore. and it didn't even look for those archived WAL files
fromsources.Once I copied back those files that I moved away during the backup restore, it completes the recovery.Now,
whyit won't recognize the WAL files from source server.Did I miss any step?
 
Sent from my BlackBerry device on the Rogers Wireless Network

On 08/02/10 10:38 AM, steeles@gmail.com wrote:
> Need some help to configure the WAl files shipping and restore it to the target server.here is what I configured in
thesource server. (both windows)In postgresql.conf, I enabled the following option.# WRITE AHEAD LOGfsync = on
    synchronous_commit = on      wal_sync_method = fsync   # - Archiving -archive_mode = onarchive_command = 'copy "%p"
"D:\\PG_DATA\\%f"'  #archive_timeout = 0   D drive is on the same source server ( I am also having trouble to ship it
totarget, had a network drive mapped in the source server, for some reason I couldn't get it copy over to this network
drive,so had to copy it local D drive first).... 

Windows network drive mappings are on a per user session basis.    the
drives you have mapped on your desktop will NOT be available to a
service, which is probably running with different user credentials, anyways

instead, use UNC names, like \\server\sharename\path\...    and also be
sure to verify that the user the service is running as (postgres ?) has
write access to the \\server\share.   this can be pretty tricky to debug.