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
- pg_rewind_corrupt_wal_v2.patch (application/octet-stream) patch v2
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
-
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