Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The pg_xlog directory for my master cluster looks like this:

-rw------- 1 postgres postgres  16M Jun 21 21:42 000000010000000000000001
-rw------- 1 postgres postgres  16M Jun 21 22:42 000000010000000000000002
-rw------- 1 postgres postgres  16M Jun 21 23:42 000000010000000000000003
-rw------- 1 postgres postgres  16M Jun 22 00:42 000000010000000000000004
-rw------- 1 postgres postgres  16M Jun 22 01:42 000000010000000000000005
-rw------- 1 postgres postgres  16M Jun 22 01:49 000000010000000000000006
-rw------- 1 postgres postgres  16M Jun 22 01:55 000000010000000000000007
-rw------- 1 postgres postgres  16M Jun 22 02:05 000000010000000000000008
-rw------- 1 postgres postgres  16M Jun 22 02:30 000000010000000000000009
-rw------- 1 postgres postgres  16M Jun 22 02:50 00000001000000000000000A

The pg_xlog/archive_status directory looks like this:

-rw------- 1 postgres postgres 0 Jun 22 01:49 000000010000000000000006.done
-rw------- 1 postgres postgres 0 Jun 22 01:55 000000010000000000000007.done
-rw------- 1 postgres postgres 0 Jun 22 02:05 000000010000000000000008.done
-rw------- 1 postgres postgres 0 Jun 22 02:30 000000010000000000000009.done

When I first turned on archiving 006 was the current segment, but why weren't 001-005 archived anyway? Last time I set up archiving on an existing cluster (which was yesterday - I've been experimenting), all log segments were archived when I turned archiving on, despite the pg_xlog directory containing more than 50 previous log segments.

Relevant settings:

wal_level = hot_standby
archive_mode = on
wal_keep_segments = 2048  # I know, right :)
archive_timeout = 3600
archive_command = 'rsync -aq --delay-updates --ignore-existing %p postgres@db-slave:/mnt/pgsql/'

Note: I did change all of these settings (including was_level, which was minimal previously) when I turned on archiving earlier. Could it be that my wal level wasn't sufficient to warrant archiving, or because there is a mismatch between the prior level and the current level?

share|improve this question
These are all good questions. I don't have answers for you off the top of my head; I'd need to go digging in the sources and do more testing than I presently have time for for a dba.SE answer. If you don't get any response here, you should try posting on pgsql-general and make sure to link back to this post. – Craig Ringer Jun 22 '13 at 11:25
@Craig - thanks, good idea. I just mailed the issue to pgsql- general. – orokusaki Jun 22 '13 at 16:47
Last time did you stopped/restarted PostgreSQL with immediate shutdown? This would explain why it archived, as it applied the xlogs on startup (with archiving enabled). – MatheusOl Jun 24 '13 at 16:47
I did a hard restart on the master, but the slave hasn't ever been started. – orokusaki Jun 24 '13 at 19:27
@MatheusOl - Sorry, I forgot to @ your name on my previous reply. – orokusaki Jun 25 '13 at 3:32
up vote 0 down vote accepted

This is most likely due to the fact that at least the 5th WAL segment was used for recovery to get the database into a consistent state after an immediate stop. I'm not sure why the WAL segments wouldn't still be useful (e.g., for point in time recovery).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.