Strahinja,
From my experience, postgres will delete WAL (after checkpoint) regardless
if they have been archived. Are you saying this is abnormal?
On Thu, Apr 25, 2013 at 7:45 PM, Strahinja Kustudić
strahin...@nordeus.comwrote:
How can the archive process fall behind? Postgres will never
German Becker wrote:
From my experience, postgres will delete WAL (after checkpoint) regardless if
they have been archived.
Are you saying this is abnormal?
That would be quite abnormal.
Could it be that your archive_command has exit status 0
even if something goes wrong?
What are the
Here is the archive part of the config:
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = '/var/lib/postgresql/scripts/archive_copy.sh %p %f'
# command to use to archive a logfile segment
The shell script call used in the archive_command is a bad idea.
Each time a new segment is archived a new shell is started and this add a
be massive overload, then and you have an extra overload for the ssh
transfer.
I suggest you to stick with the simple cp command with the test option
German Becker wrote:
Here is the archive part of the config:
archive_mode = on # allows archiving to be done
# (change requires restart)
archive_command = '/var/lib/postgresql/scripts/archive_copy.sh %p %f'
# command to use to
On Thu, Apr 25, 2013 at 12:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The cause is that each one will wait for all older snapshots to be
gone --- and it does that before dropping its own snapshot, so that the
other ones will see it as something to be waited out too.
This makes sense. Thank you
What does your shell script do that you need a script for archiving? The
archive command is usually a cp/scp/rsync command, you usually don't need
more than that.
Regards,
Strahinja
On Fri, Apr 26, 2013 at 3:55 PM, Albe Laurenz laurenz.a...@wien.gv.atwrote:
German Becker wrote:
Here is the
Hi I have reverted to cp as archive command, but know under heavy load (
150 WAL segments in a minute) it happens that some wal segments gets
corrupted:
postgres@lemur:~/9.1/main/pg_xlog$ md5sum 000100100049
f1906d2745224430f811496df466203f 000100100049
