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

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Michael Paquier' <michael@paquier.xyz>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-03-09T08:22:49Z
Lists: pgsql-hackers

Attachments

From: Michael Paquier [mailto:michael@paquier.xyz]
> I see.  So the only reason why this flag exists is that if a file is large
> enough so as it is split into multiple chunks, then the first unlink will
> work but not the successive ones.  One chunk can be at most
> 1 million bytes, which is why it is essential for WAL segments.  Instead
> of ignoring *all* errors, let's ignore only ENOENT and rename ignore_error
> to missing_ok as well.
> 
> You need to update the comment in receiveFileChunks where an entry gets
> deleted with basically what I mentioned above, say:
> "If a file has been deleted on the source, remove it on the target as well.
> Note that multiple unlink() calls may happen on the same file if multiple
> data chunks are associated with it, hence ignore unconditionally anything
> missing.  If this file is not a relation data file, then it has been already
> truncated when creating the file chunk list at hte previous execution of
> the filemap."
> 
> Adding also a comment on top of remove_target_file to explain what
> missing_ok does would be nice to keep track of what the code should do.

Thanks for reviewing.  All done.

Regards
Takayuki Tsunakawa

Commits

  1. Fix handling of files that source server removes during pg_rewind is running.