Re: Aborted VACUUM FULL -> crash + corruption (xlog non-existent)
От | Peter Schuller |
---|---|
Тема | Re: Aborted VACUUM FULL -> crash + corruption (xlog non-existent) |
Дата | |
Msg-id | 20080826162235.GA49557@hyperion.scode.org обсуждение исходный текст |
Ответ на | Re: Aborted VACUUM FULL -> crash + corruption (xlog non-existent) (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Aborted VACUUM FULL -> crash + corruption (xlog
non-existent)
Re: Aborted VACUUM FULL -> crash + corruption (xlog non-existent) |
Список | pgsql-bugs |
> > -rw------- 1 postgres postgres 16777216 Aug 26 17:16 00000001000000180= 00000EE > > drwx------ 2 postgres postgres 305232 Aug 26 17:14 archive_status > >=20 > > Note that the archival of the ....ED xlog file started at 17:14:52, > > and I cancelled the VACUUM FULL at 17:16:06. >=20 > What's your archive_command? archive_command =3D '/path/to/wal-archive.sh "%p" "%f"' (only path to script changed for privacy) The script just removes the archive file; the intent was to have archival enabled such that we could start using it for real without re-starting the server in the future. The script contents is: =3D=3D=3D #!/bin/bash set -e path=3D"$1" file=3D"$2" # put segment somewhere useful here rm $path echo "$(date): $path" > /tmp/wal-archive-stamp exit 0 =3D=3D=3D 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 somewhere or similar). 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. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org
В списке pgsql-bugs по дате отправления: