Recuperar banco de dados PostgreSQL de erros do WAL na inicialização?

Estou tentando configurar um servidor OpenStreetMap em uma máquina Ubuntu 12.04 usando os pacotes Ubuntu listados em switch2osm.org . Inicialmente, instalei e configurei tudo usando uma extração de mapa do nordeste dos EUA, mas agora quero instalar todo o planeta de mapas. Baixei planet-latest.osm.bz2 e executei osm2pgsql --slim -C 60000 planet-latest.osm.bz2como um usuário com permissão de gravação no banco de dados; este foi o mesmo comando que funcionou para instalar us-northeast.osm.pbf anteriormente. Voltei no dia seguinte para descobrir que esse comando parecia ter sido concluído com sucesso, mas por algum motivo o daemon de renderização não estava gerando novos blocos a partir dos novos dados. Tentei reiniciar o renderizado e, quando isso não teve efeito, tentei reiniciar o servidor PostgreSQL com sudo /etc/init.d/postgresql restart. No entanto, a inicialização do servidor falhou com os seguintes erros no log:

2012-07-13 18:54:59 UTC WARNING:  page 1525147 of relation base/16385/477861 was uninitialized
2012-07-13 18:54:59 UTC WARNING:  page 2247965 of relation base/16385/477861 was uninitialized
...500 more lines like this...
2012-07-13 18:54:59 UTC WARNING:  page 2262926 of relation base/16385/477861 was uninitialized
2012-07-13 18:54:59 UTC PANIC:  WAL contains references to invalid pages
2012-07-13 18:55:00 UTC LOG:  startup process (PID 22826) was terminated by signal 6: Aborted

(Pastebin de log inteiro aqui ).

Não há muita informação sobre esses tipos de erros na Internet, mas pelo que posso descobrir, parece significar que meus índices estão corrompidos ou meu Write-Ahead-Log está. A única maneira de corrigir índices corrompidos, no entanto, é iniciar o banco de dados no modo de usuário único e reconstruí-los, e nem posso fazer isso porque recebo os mesmos erros fatais mesmo quando começo no modo de usuário único com indexação Desativado.

Existe alguma maneira de excluir o log Write-Ahead e forçar o servidor a inicializar "do zero" ou uma correção para esse tipo de corrupção que não requer a inicialização do banco de dados com êxito?

Como alternativa, existe uma maneira de excluir o banco de dados e apenas reimportar todos os dados do planeta, visto que não consigo iniciar o servidor para executar o comando DROP DATABASE?

ATUALIZAÇÃO :

Seguindo a sugestão de Craig Ringer, examinei os logs do banco de dados antes de os erros do WAL começarem a ocorrer para ver se encontrava algum comportamento suspeito. No log imediatamente antes da primeira ocorrência de erros do WAL, encontrei estas linhas de aparência suspeita:

2012-07-13 00:20:51 UTC LOG:  received fast shutdown request
2012-07-13 00:20:51 UTC LOG:  aborting any active transactions
2012-07-13 00:20:51 UTC FATAL:  terminating connection due to administrator command
2012-07-13 00:20:51 UTC FATAL:  terminating connection due to administrator command
2012-07-13 00:20:51 UTC FATAL:  terminating connection due to administrator command
2012-07-13 00:20:51 UTC FATAL:  terminating connection due to administrator command
2012-07-13 00:20:54 UTC FATAL:  terminating connection due to administrator command
2012-07-13 00:20:54 UTC STATEMENT:  CREATE TABLE planet_osm_polygon_tmp AS SELECT * 
FROM planet_osm_polygon ORDER BY way;

2012-07-13 00:20:55 UTC FATAL:  terminating connection due to administrator command
2012-07-13 00:20:55 UTC STATEMENT:  CREATE INDEX planet_osm_ways_nodes ON planet_osm_ways 
USING gin (nodes)  WITH (FASTUPDATE=OFF);

2012-07-13 00:20:57 UTC FATAL:  terminating connection due to administrator command
2012-07-13 00:20:57 UTC STATEMENT:  CREATE TABLE planet_osm_line_tmp AS SELECT * 
FROM planet_osm_line ORDER BY way;

2012-07-13 00:21:51 UTC LOG:  received immediate shutdown request
2012-07-13 00:21:52 UTC WARNING:  terminating connection because of crash of another
server process
2012-07-13 00:21:52 UTC DETAIL:  The postmaster has commanded this server process 
to roll back the current transaction and exit, because another server process 
exited abnormally and possibly corrupted shared memory.
2012-07-13 00:21:52 UTC HINT:  In a moment you should be able to reconnect to the 
database and repeat your command.
2012-07-13 00:21:52 UTC LOG:  could not send data to client: Broken pipe
2012-07-13 00:21:58 UTC WARNING:  terminating connection because of crash of another 
server process
2012-07-13 00:21:58 UTC DETAIL:  The postmaster has commanded this server process 
to roll back the current transaction and exit, because another server process
exited abnormally and possibly corrupted shared memory.
2012-07-13 00:21:58 UTC HINT:  In a moment you should be able to reconnect to the
 database and repeat your command.
2012-07-13 00:21:58 UTC LOG:  could not send data to client: Broken pipe

(Pastebin de todo o log está aqui )

Quando diz "terminando a conexão devido ao comando do administrador", presumo que esse seja o meu comando para reiniciar o servidor de banco de dados. Mas parece que o desligamento de alguma forma falhou terrivelmente, resultando em corrupção de memória compartilhada. Isso não faz sentido, porque eu o reiniciei "limpamente", usando o /etc/init.d/postgres restartscript, não uma morte abrupta ou login manual como postgres. Estou interpretando este log incorretamente? Ou existe realmente um problema em usar /etc/init.d/postgres restartpara reiniciar um servidor PostgreSQL?

(Observe que, como minha pergunta foi movida para o administrador do banco de dados, onde sou um "novo usuário", não tenho mais a capacidade de votar em suas respostas. Isso não significa que não aprecio a ajuda).