4

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?

7
  • 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. Jun 22, 2013 at 11:25
  • @Craig - thanks, good idea. I just mailed the issue to pgsql- general.
    – orokusaki
    Jun 22, 2013 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, 2013 at 16:47
  • I did a hard restart on the master, but the slave hasn't ever been started.
    – orokusaki
    Jun 24, 2013 at 19:27
  • @MatheusOl - Sorry, I forgot to @ your name on my previous reply.
    – orokusaki
    Jun 25, 2013 at 3:32

1 Answer 1

0

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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