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: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, vladimirlesk@yandex-team.ru, Dmitriy Sarafannikov <dsarafan@yandex-team.ru>
Date: 2018-10-25T12:37:18Z
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 22.10.2018 20:19, Alvaro Herrera wrote:
>>> I didn't actually try patch yet, but the idea seems interesting. Will
>>> you add it to the commitfest?
>> I am willing to add it to the November commitfest, but I have some concerns
>> regarding frontend version of GUC parser. Probably, it is possible to
>> refactor guc-file.l to use it on both front- and backend. However, it
>> requires usage of IFDEF and mocking up ereport for frontend, which is a bit
>> ugly.
> Hmm, I remember we had a project to have a new postmaster option that
> would report the value of some GUC option, so instead of parsing the
> file in the frontend, you'd invoke the backend to do the parsing.  But I
> don't know what became of that ...

Brief searching in the mailing list doesn't return something relevant, 
but the project seems to be pretty straightforward at first sight.
> Of course, recovery.conf options are not GUCs either ... that's another
> pending patch.
>
> We do have some backend-mock for frontends, e.g. in pg_waldump; plus
> palloc is already implemented in libpgcommon.  I don't know if what you
> need to compile the lexer is a project much bigger than finishing the
> other two patches I mention.

This thing, in opposite, is a long-living, there are several threads 
starting from the 2011th. I have found Michael's, Simon's, Fujii's 
patches and Greg Smith's proposal (see, e.g. [1, 2]). If I get it right, 
the main point is that if we turn all options in the recovery.conf into 
GUCs, then it becomes possible to set them inside postgresql.conf and 
get rid of recovery.conf. However, it ruins backward compatibility and 
brings some other issues noted by Heikki 
https://www.postgresql.org/message-id/5152F778.2070205@vmware.com, while 
keeping both options is excess and ambiguous.

Thus, though everyone agreed that recovery.conf options should be turned 
into GUCs, there is still no consensus in details. I don't think that I 
know Postgres architecture enough to start this discussion again, but 
thank you for pointing me in this direction, it was quite interesting 
from the historical perspective.

I will check guc-file.l again, maybe it is not so painful to make it 
frontend-safe too.


[1] 
https://www.postgresql.org/message-id/flat/CAHGQGwHi%3D4GV6neLRXF7rexTBkjhcAEqF9_xq%2BtRvFv2bVd59w%40mail.gmail.com

[2] 
https://www.postgresql.org/message-id/flat/CA%2BU5nMKyuDxr0%3D5PSen1DZJndauNdz8BuSREau%3DScN-7DZ9acA%40mail.gmail.com

-- 
Alexey Kondratov

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