Re:Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WALfiles - Mailing list pgsql-hackers

From chenhj
Subject Re:Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WALfiles
Date
Msg-id 35c3d9e3.54.16129300ae8.Coremail.chjischj@163.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files
List pgsql-hackers

At 2018-01-23 09:56:48, "Stephen Frost" <sfrost@snowman.net> wrote: > >I've only read through the thread to try and understand what's going on >and the first thing that comes to mind is that you're changing >pg_rewind to not remove the WAL from before the divergence (split) >point, but I'm not sure why. As noted, that WAL isn't needed for >anything (it's from before the split, after all), so why keep it? Is >there something in this optimization that depends on the old WAL being >there and, if so, what and why?

After run pg_rewind, the first startup of postgres will do crash recovery. And crash recovery will begin from the previous redo point preceding the divergence. So, the WAL after the redo point and before the divergence is needed.
Of course, the WAL before the redo point is not needed, but in my point of view, recycling unwanted WAL does not have to be done by pg_rewind. reference code: pg_rewind.c: main(int argc, char **argv) { ... findLastCheckpoint(datadir_target, divergerec, lastcommontliIndex, &chkptrec, &chkpttli, &chkptredo); ... createBackupLabel(chkptredo, chkpttli, chkptrec); ... } ... createBackupLabel(XLogRecPtr startpoint, TimeLineID starttli, XLogRecPtr checkpointloc) { ...len = snprintf(buf, sizeof(buf), "START WAL LOCATION: %X/%X (file %s)\n" "CHECKPOINT LOCATION: %X/%X\n" "BACKUP METHOD: pg_rewind\n" "BACKUP FROM: standby\n" "START TIME: %s\n",/* omit LABEL: line */ (uint32) (startpoint >> 32), (uint32) startpoint, xlogfilename, (uint32) (checkpointloc >> 32), (uint32) checkpointloc, strfbuf); ... }


>That's also different from how pg_basebackup works, which I don't think >is good (seems like pg_rewind should operate in a pretty similar manner >to pg_basebackup). >
Thanks for your comments! I also considered copy WAL just like how pg_basebackup does,but a implement similar to pg_basebackup's manner may be not so simple.
Twice transport of files from source to target may be needed,first for data files, and another for WAL. And the WAL which contains the previous redo point preceding the divergence may be only exists in target server and had been recycled in source. That's different between pg_rewind and pg_basebackup.

Regards,
Chen Huajun



pgsql-hackers by date:

Previous
From: Arthur Zakirov
Date:
Subject: Re: [PROPOSAL] Shared Ispell dictionaries
Next
From: Tomas Vondra
Date:
Subject: Re: copy.c allocation constant