Re: Skip checkpoint on promoting from streaming replication

Hello, This is the new version of the patch.

Your patch introduced new WAL record type XLOG_END_OF_RECOVERY to
mark the chenge point of TLI. But I think the information is
already stored in history files and already ready to use in
current code.

I looked into your first patch and looked over the discussion on
it, and find that my understanding that TLI switch is operable
also for crash recovery besides archive recovery was half
wrong. The correct half was that it can be operable for crash
recovery if we properly set TimeLineID in StartupXLOG().

To achieve this, I added a new field 'latestTLI' (more proper
name is welcome) and make it always catch up with the latest TLI
with no relation to checkpoints. Then set the recovery target in
StartupXLOG() referring it. Additionaly, in previous patch, I
checked only checkpoint intervals but this ended with no effect
as you said. Because the WAL files in pg_xlog are preserved as
many as required for crash recovery, as I knew...


The new patch seems to work correctly for changing of TLI without
checkpoint following.  And archive recovery and PITR also seems
to work correctly. The test script for the former is attached
too.

The new patch consists of two parts. These might should be
treated as two separate ones..

1. Allow_TLI_Increment_without_Checkpoint_20120618.patch

  Removes the assumption after the 'convension' that TLI should
  be incremented only on shutdown checkpoint. This seems actually
  has no problem as the commnet(This is not particularly
  critical).

2. Skip_Checkpoint_on_Promotion_20120618.patch

  Skips checkpoint if redo record can be read in-place.

3. Test script for TLI increment patch.

  This is only to show how the patch is tested. The point is
  creating TLI increment point not followed by any kind of
  checkpoints.  pg_controldata shows like following after running
  this test script. Latest timeline ID is the new field.

   > pg_control version number:            923
   > Database cluster state:               in production
  !> Latest timeline ID:                   2
   > Latest checkpoint location:           0/2000058
   > Prior checkpoint location:            0/2000058
   > Latest checkpoint's REDO location:    0/2000020
  !> Latest checkpoint's TimeLineID:       1

  We will see this changing as follows after crash recovery,

   > Latest timeline ID:                   2
   > Latest checkpoint location:           0/54D9918
   > Prior checkpoint location:            0/2000058
   > Latest checkpoint's REDO location:    0/54D9918
   > Latest checkpoint's TimeLineID:       2

  Then, we should see both two 'ABCDE...'s and two 'VWXYZ...'s in
  the table after the crash recovery.

What do you think about this?

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

== My e-mail address has been changed since Apr. 1, 2012.