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.Grittner@xxxxxxxxxxxx> wrote: > "Bruce Reed" <breed@xxxxxxxxxxx> 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
