RE: [bug fix] pg_rewind creates corrupt WAL files, and the standby cannot catch up the primary

From: Michael Paquier [mailto:michael(at)paquier(dot)xyz]
> 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.

Thank you for information. I didn't notice those activities going around pg_rewind.

It's a regret that Chen's patch, which limits the WAL to be copied, is not committed yet. It looks good to be ready for committer.

> > 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/

Wow, what a great patch. I think I should look at it. But I'm afraid it won't be backpatched because it's big...

Even with your patch and Chen's one, my small patch is probably necessary to avoid leaving 0-byte or half-baked files. I'm not sure whether those strangely sized files would cause actual trouble, but maybe it would be healthy to try to clean things up as much as possible. (files in pg_twophase/ might emit WARNING messages, garbage server log files might make the DBA worried, etc.; yes, these may be just FUD.)

Regards
Takayuki Tsunakawa