Re: WAL ends before end time of backup dump

Which Sunday? Could you have been bitten by some DST time shift? There
were 2 1ams a couple of weeks ago.

Woody
IGLASS Networks

-----Original Message-----
From: pgsql-general-owner(at)postgresql(dot)org
[mailto:pgsql-general-owner(at)postgresql(dot)org] On Behalf Of Jeff Davis
Sent: Tuesday, November 07, 2006 5:38 PM
To: Tom Lane
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: [GENERAL] WAL ends before end time of backup dump

On Tue, 2006-11-07 at 17:20 -0500, Tom Lane wrote:
> Jeff Davis <pgsql(at)j-davis(dot)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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster