Re: [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary
Date
Msg-id 20180301015952.GC1178@paquier.xyz
Whole thread Raw
In response to [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Synchronous replay take III
Next
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning