On 05.03.2020 09:24, Michael Paquier wrote:
On Wed, Mar 04, 2020 at 08:14:20PM +0300, Alexey Kondratov wrote:
- I did not actually get why you don't check for a missing command
when using wait_result_is_any_signal. In this case I'd think that it
is better to exit immediately as follow-up calls would just fail.
Believe me or not, but I put 'false' there intentionally. The idea was that
if the reason is a signal, then maybe user tired of waiting and killed that
restore_command process theirself or something like that, so it is better to
exit immediately. If it was a missing command, then there is no hurry, so we
can go further and complain that attempt of recovering WAL segment has
failed.
Actually, I guess that there is no big difference if we include missing
command here or not. There is no complicated logic further compared to real
recovery process in Postgres, where we cannot simply return false in that
case.
On the contrary, it seems to me that the difference is very important.
Imagine for example a frontend tool which calls RestoreArchivedWALFile
in a loop, and that this one fails because the command called is
missing. This tool would keep looping for nothing. So checking for a
missing command and leaving immediately would be more helpful for the
user. Can you think about scenarios where it would make sense to be
able to loop in this case instead of failing?
OK, I was still having in mind pg_rewind as the only one user of this
routine. Now it is a part of the common and I could imagine a
hypothetical tool that is polling the archive and waiting for a specific
WAL segment to become available. In this case 'command not found' is
definitely the end of game, while the absence of segment is expected
error, so we can continue looping.
Regards
--
Alexey Kondratov
Postgres Professional https://www.postgrespro.com
Russian Postgres Company
