Re: WAL ends before end time of backup dump

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: WAL ends before end time of backup dump
Дата
Msg-id 1162939069.31124.429.camel@dogma.v10.wvs
обсуждение исходный текст
Ответ на Re: WAL ends before end time of backup dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: WAL ends before end time of backup dump  ("Woody Woodring" <george.woodring@iglass.net>)
Список pgsql-general
On Tue, 2006-11-07 at 17:20 -0500, Tom Lane wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
> > LOG:  restored log file "00000001000000170000002B" from archive
> > LOG:  record with zero length at 17/2B6EACC8
> > LOG:  redo done at 17/2B6EAC84
>
> It looks to me like you archived this log file before it was fully
> written.  You should take a close look at your archiving procedures.
>

Hmm... the only way the file gets there is archive command. I didn't do
any manual moves of the segments, certainly not last Sunday at 1am
(which is when this segment was put there).

From postgresql.conf:
archive_command = '/usr/local/pgsql/bin/archive_command.bash "%p" "%f"'

and:
-----------
$ cat /usr/local/pgsql/bin/archive_command.bash
#!/usr/local/bin/bash

# $1 is the full path to the file to archive
# $2 is the filename

WAL=$1
WAL_NAME=$2
WAL_ARCHIVE=/path/to/archive

echo test ! -f $WAL_ARCHIVE/$WAL_NAME && gzip -c $WAL >
$WAL_ARCHIVE/$WAL_NAME.gz
------------

Any obvious holes in there? Is gzip doing something weird? It worked
with all my other WAL segments, and I've tested the backups multiple
times.

Also, the WAL segment is exactly the right size, although I suppose
there's no way for it not to be.

Regards,
    Jeff Davis


В списке pgsql-general по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: WAL ends before end time of backup dump
Следующее
От: gurkan@resolution.com
Дата:
Сообщение: converting Informix outer to Postgres