Thanks everyone for your answers and pointing me to relevant documentation! I will attempt to do a dump and restore immediately after pg_resetxlog and see where that leaves me.
It is indeed a one off for us. Generally we have a complete WAL-history.
> If you absolutely must use the pg_basebackup as your source and I'm assuming > you have a tarball without any of WAL files, you could expand the tarball > into you data directory, and use pg_resetxlog to "fool" the master into > starting up. I only say "fool" as it just builds you a blank WAL file which > this system can use as its integrity check and properly start.
Please note that this will generally leave you with a corrupted cluster; you would be well advised to follow the advice in the documentation:
| After running this command, it should be possible to start the | server, but bear in mind that the database might contain | inconsistent data due to partially-committed transactions. You | should immediately dump your data, run initdb, and reload. After | reload, check for inconsistencies and repair as needed.
Hopefully this is just a one-off occurrence where you needed to do this. The best thing long term would be to ensure you're backing up the WAL files along with pg_basebackup. Use the -X option with pg_basebackup so you have a consistent backup that can be started on its own. Or make sure you're backing up your WAL files another way (archive_command on master, pg_receivexlogs, etc).
