Re: Making pg_rewind faster - Mailing list pgsql-hackers

From Srinath Reddy Sadipiralla
Subject Re: Making pg_rewind faster
Date
Msg-id CAFC+b6pg5f7nGP+w3MgZO15ZT3z=x0e3tkkAQbqvYD0R410sug@mail.gmail.com
Whole thread Raw
In response to Re: Making pg_rewind faster  (John H <johnhyvr@gmail.com>)
Responses Re: Making pg_rewind faster
List pgsql-hackers

Hi,

just a second late :( i was about to post a patch addressing the refactors which Robert mentioned  ,anyway will have a look at your latest patch John thanks :), curious about the tap test.

while i was writing the patch something suddenly struck me , that is why we are even depending on last_common_segno ,because once we reached decide_wal_file_action it means that the file exists in both target and source ,AFAIK this can only happen with wal segments older than or equal to last_common_segno because once the promotion competes the filename of the WAL files gets changed with the new timelineID(2), for ex: if the last_common_segno is 000000010000000000000003 then based on the rules in XLogInitNewTimeline 
1) if the timeline switch happens in middle of segment ,copy data from the last WAL segment and create WAL file with same segno but different timelineID,in this case the starting WAL file for the new timeline will be 000000020000000000000003
2) if the timeline switch happens at segment boundary , just create next segment for this case the starting WAL file for the new timeline will be 000000020000000000000004

so basically the files which exists in source and not in target like the new timeline WAL segments will be copied to target in total before we reach decide_wal_file_action , so i think we don't need to think about copying WAL files after divergence point by calculating and checking against last_common_segno which we are doing in our current approach , i think we can just do 

in decide_wal_file_action

if (entry->target_size != entry->source_size)
{
pg_log_debug("WAL segment file \"%s\" is copied to target", fname);
return FILE_ACTION_COPY;
}
return FILE_ACTION_NONE;

thoughts?

--
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

pgsql-hackers by date:

Previous
From: Mario González Troncoso
Date:
Subject: Re: meson's in-tree libpq header search order vs -Dextra_include_dirs
Next
From: Jeff Davis
Date:
Subject: Re: Expanding HOT updates for expression and partial indexes