BUG #15335: Documentation is wrong about archive_command and existingfiles
От | PG Bug reporting form |
---|---|
Тема | BUG #15335: Documentation is wrong about archive_command and existingfiles |
Дата | |
Msg-id | 153443580087.1505.359622154765650394@wrigleys.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #15335: Documentation is wrong about archive_command andexisting files
Re: BUG #15335: Documentation is wrong about archive_command andexisting files Re: BUG #15335: Documentation is wrong about archive_command andexisting files |
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 15335 Logged by: Phil Endecott Email address: spam_from_pgsql_lists@chezphil.org PostgreSQL version: 9.6.10 Operating system: Debian Stretch Description: The docs in section 25.3.1 say that archive_command should check if the target file already exists and fail in that case. It seems that this is not entirely true; the command should succeed if the target file already exists and its content is the same as the source. This is explicitly mentioned in section 26.2.9 for the case of cascaded replication with a shared archive, but I understand that this is actually needed in all cases. I encountered this during a failed attempt at promotion, but there are likely to be other cases. Quoting David Steele from the -general mailing list: "Duplicate WAL is possible in *all* cases. A trivial example is that Postgres calls archive_command and it succeeds but an error happens (e.g. network) right before Postgres is notified. It will wait a bit and try the same WAL segment again." Note that the example archive commands in the documentation (using cp) get this wrong. Minimal examples of archive commands that do this check correctly would be very useful. (I worry that the non-WAL files that archive_command and restore_command are also invoked for, e.g. the .backup and .history files, have some additional or possibly even conflicting requirements.)
В списке pgsql-bugs по дате отправления: