RE: [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary
| От | Tsunakawa, Takayuki |
|---|---|
| Тема | RE: [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary |
| Дата | |
| Msg-id | 0A3221C70F24FB45833433255569204D1F9000B9@G01JPEXMBYT05 обсуждение исходный текст |
| Ответ на | Re: [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: [bug fix] pg_rewind creates corrupt WAL files, and the standbycannot catch up the primary
|
| Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: