Re: [bug fix] pg_rewind creates corrupt WAL files, and the standby cannot catch up the primary
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-03-01T01:59:52Z
Lists: pgsql-hackers
On Thu, Mar 01, 2018 at 01:26:32AM +0000, Tsunakawa, Takayuki wrote: > BTW, should pg_rewind really copy WAL files from the primary? If the > sole purpose of pg_rewind is to recover an instance to use as a > standby, can pg_rewind just remove all WAL files in the target > directory, because the standby can get WAL files from the primary > and/or archive? Yes, it should not copy those WAL files. Most of the time they are going to be meaningless. See this recent thread: https://www.postgresql.org/message-id/20180126023609.GH17847%40paquier.xyz So I would rather go this way instead of having to worry about manipulating those WAL segments as you do. Depending on the needs, I think that even a backpatch could be considered. > Related to this, shouldn't pg_rewind avoid copying more files and > directories like pg_basebackup? Currently, pg_rewind doesn't copy > postmaster.pid, postmaster.opts, and temporary files/directories > (pg_sql_tmp/). Yes, it should not copy those files. I have a patch in the current CF to do that: https://commitfest.postgresql.org/17/1507/ -- Michael
Commits
-
Fix handling of files that source server removes during pg_rewind is running.
- b33e38cb1e14 9.5.13 landed
- 52c32d8d8d3c 9.6.9 landed
- f1e07d576318 10.4 landed
- 09e96b3f3562 11.0 landed