Re: Continuous archiving fails routinely with "invalid magic number" error

I can, though I think I'll tweak the pg_standby parms and see if linking
instead of copying fixes the problem. pg_standby would be at fault here,
wouldn't it? It seems NFS transport is a common way to manage this, in fact
it's mentioned as a solution on the Continuous Archiving doc page. It's a
fast link with low latency and NFS copy is only slightly slower than local
disk copy. I thought with NFS 3 and synchronous write the remote end can't
put the cart before the horse.

Maybe debug output will turn up something on next failure.

Bruce

On 5/28/09 5:18 PM, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:

> "Bruce Reed" <breed(at)dvdplay(dot)com> wrote:
>
>> May 26 08:58:55 ods2-prod postgres[3827]: [1427-1] LOG: invalid
>> magic number 0000 in log file 194, segment 229, offset 10780672
>
> Try copying to a different name or directory on the target volume and
> renaming or moving into place. It sounds as though maybe the copy is
> allocating the file at full size and then copying in the contents, and
> the recovery process is sometimes picking it up before it's done.
> Either that or the file is being corrupted in transit.
>
> -Kevin