Re:Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files

From: chenhj <chjischj(at)163(dot)com>
To: "Stephen Frost" <sfrost(at)snowman(dot)net>
Cc: "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com>, "Alexander Korotkov" <a(dot)korotkov(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re:Re: [HACKERS] [PATCH]make pg_rewind to not copy useless WAL files
Date: 2018-01-24 17:21:09
Message-ID: 35c3d9e3.54.16129300ae8.Coremail.chjischj@163.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


At 2018-01-23 09:56:48, "Stephen Frost" <sfrost(at)snowman(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-01-24 17:25:01 Re: copy.c allocation constant
Previous Message Arthur Zakirov 2018-01-24 17:20:41 Re: [PROPOSAL] Shared Ispell dictionaries