From: "Jeff Janes" <jeff.ja...@gmail.com>
Do people really just copy the files from one directory of local storage
to
another directory of local storage? I don't see the point of that.
It makes sense to archive WAL to a directory of local storage for media
recovery. Here, the local storage is a different disk drive which is
directly attached to the database server or directly connected through SAN.
The recommendation is to refuse to overwrite an existing file of the same
name, and exit with failure. Which essentially brings archiving to a
halt,
because it keeps trying but it will keep failing. If we make a custom
version, one thing it should do is determine if the existing archived file
is just a truncated version of the attempting-to-be archived file, and if
so overwrite it. Because if the first archival command fails with a
network glitch, it can leave behind a partial file.
What I'm trying to address is just an alternative to cp/copy which fsyncs a
file. It just overwrites an existing file.
Yes, you're right, the failed archive attempt leaves behind a partial file
which causes subsequent attempts to fail, if you follow the PG manual.
That's another undesirable point in the current doc. To overcome this,
someone on this ML recommended me to do "cp %p /archive/dir/%f.tmp && mv
/archive/dir/%f.tmp /archive/dir/%f". Does this solve your problem?
Regards
MauMau
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
