Peter Schuller wrote:
> I will go hide in a corner now...
FWIW, as soon as you come out of the corner, you can solve the problem
easily by manually copying the file back from the archive location into
pg_xlog and restarting the server.
--
Alvaro Herrerahttp://www
Peter Schuller wrote:
> It would be embarressing if I caused this problem myself by
> misunderstanding wal_archiving. My understanding has been that once
> wal_archive gets called, no one ever cares what happens with the file
> except if I want to do PITR (since the whole point is to offload it
>
> I'll go and re-read the documentation on this immediately. If this is
> the problem, I do apologies for the noise and people's time.
So it is, as far as I can tell. The script should not remove the
file. I don't know what I was thinking. This was not a smart thing to
do...
I sincerely apologies
> > -rw--- 1 postgres postgres 16777216 Aug 26 17:16
> > 0001001800EE
> > drwx-- 2 postgres postgres 305232 Aug 26 17:14 archive_status
> >
> > Note that the archival of the ED xlog file started at 17:14:52,
> > and I cancelled the VACUUM FULL at 17:16:06.
>
> What's
Peter Schuller wrote:
> The pg_xlog directory contains:
>
> -rw--- 1 postgres postgres 16777216 Aug 26 17:16 0001001800EE
> drwx-- 2 postgres postgres 305232 Aug 26 17:14 archive_status
>
> Note that the archival of the ED xlog file started at 17:14:52,
> and I cancel
Hello,
[note: in pastes below, the only thing changes are database names and
hostnames, for privacy reasons; otherwise plain cut'n'paste including
typos...)
Very short version: I cancelled a VACUUM FULL; server crashed; won't
start again because it tries to access an obsolete WAL log file that
is
