Horton

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

Alexey Kondratov <a.kondratov@postgrespro.ru>

View thread
From: Alexey Kondratov <a.kondratov@postgrespro.ru>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>, Alvaro Herrera <alvherre@2ndquadrant.com>, Liudmila Mantrova <l.mantrova@postgrespro.ru>, Thomas Munro <thomas.munro@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>, David Steele <david@pgmasters.net>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Dmitry Dolgov <9erthalion6@gmail.com>, vladimirlesk@yandex-team.ru, dsarafan@yandex-team.ru
Date: 2020-03-05T16:52:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Move frontend-side archive APIs from src/common/ to src/fe_utils/

  2. Add -c/--restore-target-wal to pg_rewind

  3. Move routine definitions of xlogarchive.c to a new header file

  4. Move routine building restore_command to src/common/

  5. Integrate recovery.conf into postgresql.conf

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