Hello,
I'm having a problem with a warm standy-by / continuous archiving setup.
The archive of WAL segments on the "slave" server sometimes (and only
sometimes) grows _huge_.
I'm using a warm standy-by / continuous archiving setup with two
servers. The "slave" servers, in stand-by mode, is processing WAL
segments shipped from the "master" server using "restore_command" in
recovery.conf. restore_command calls a scripts that subsequently uses
pg_standby to process the WAL's:
The setup uses "restore_command" in recovery.conf to call a script that
subsequently calls pg_standby to process the WAL's:
restore_command='/blabla/restore.sh %f %p %r'
and, in restore.sh:
.
.
/usr/lib/postgresql/8.3/bin/pg_standby -d -s 5 -t /tmp/pgsql.trigger
/blabla/remote_logs "$f" "$p" "$r"
.
.
As I understand it, the %r variable passed to restore_command is the
name of the oldest file that needs to be kept, "containing the last
valid restart point."
Normally, I see increments to this parameter in calls to restore_command
and then pg_standby removing older WAL's.
Then sometimes, the value of the %r parameter in calls of
restore_command never changes any more, pg_standby then does not remove
any WAL's anymore, the partition hosting the WAL's from the master
server fills up.
I don't precisely understand how the %r value passed to restore_command
is calculated. Could the problem be some long lasting transaction on the
master? Any other condition I could check? The documentation states that
%r points to the WAL with the last valid restart point. However, I could
not find a further definition of the term "restart point" in the
Postgres manual.
Any ideas?
Regards,
Duco Fijma
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
