pgsql: Fix recycling of WAL segments after changing recovery target tim

From: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Fix recycling of WAL segments after changing recovery target tim
Date: 2012-12-20 20:04:40
Message-ID: E1TlmMC-0007LZ-Dn@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Fix recycling of WAL segments after changing recovery target timeline.

After the recovery target timeline is changed, we would still recycle and
preallocate WAL segments on the old target timeline. Those WAL segments
created for the old timeline are a waste of space, although otherwise
harmless.

The problem is that when installing a recycled WAL segment as a future one,
ThisTimeLineID is used to construct the filename. ThisTimeLineID is
initialized in the checkpointer process to the recovery target timeline at
startup, but it was not updated when the startup process chooses a new
target timeline (recovery_target_timeline='latest'). To fix, always update
ThisTimeLineID before recycling WAL segments at a restartpoint.

This still leaves a small window where we might install WAL segments under
wrong timeline ID, if the target timeline is changed just as we're about to
start recycling. Also, when we're not on the target timeline yet, but still
replaying some older timeline, we'll install WAL segments to the newer
timeline anyway and they will still go wasted. We'll just live with the
waste in that situation.

Commit to 9.2 and 9.1. Older versions didn't change recovery target timeline
after startup, and for master, I'll commit a slightly different variant of
this.

Branch
------
REL9_1_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/0d0501e80fbbe51a885b4fe2fe3b4f22ef3bed66

Modified Files
--------------
src/backend/access/transam/xlog.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2012-12-20 21:32:20 pgsql: Fix pg_extension_config_dump() to handle update cases more sanel
Previous Message Bruce Momjian 2012-12-20 18:56:33 pgsql: Avoid using NAMEDATALEN in pg_upgrade