From: | Bruce Reed <breed(at)dvdplay(dot)com> |
---|---|
To: | "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: Continuous archiving fails routinely with "invalid magic number" error |
Date: | 2009-05-29 03:43:55 |
Message-ID: | C644A80B.7387%breed@dvdplay.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-05-29 14:21:26 | Re: Continuous archiving fails routinely with "invalid magic number" error |
Previous Message | Scott Marlowe | 2009-05-29 03:27:37 | Re: Pre-creating partitions incurs insert penalty |