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

Alexey Kondratov <a.kondratov@postgrespro.ru>

From: Alexey Kondratov <a.kondratov@postgrespro.ru>
To: Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>, Kuntal Ghosh <kuntalghosh.2007@gmail.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-12T12:57:49Z
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 12.03.2020 07:39, Michael Paquier wrote:
> I'd like to commit the refactoring piece in 0001 tomorrow, then let's
> move on with the rest as of 0002.  If more comments and docs are
> needed for archive.c, let's continue discussing that.

I just went through the both patches and realized that I cannot get into 
semantics of splitting frontend code between common and fe_utils. This 
applies only to 0002, where we introduce fe_archive.c. Should it be 
placed into fe_utils alongside of the recent recovery_gen.c also used by 
pg_rewind? This is a frontend-only code intended to be used by frontend 
applications, so fe_utils feels like the right place, doesn't it? Just 
tried to do so and everything went fine, so it seems that there is no 
obstacles from the build system.

BTW, most of 'common' is a really common code with only four exceptions 
like logging.c, which is frontend-only. Is it there for historical 
reasons only or something else?


Regards

-- 
Alexey Kondratov

Postgres Professional https://www.postgrespro.com
Russian Postgres Company