Date: Mon, 22 Oct 2018 14:19:07 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Alexey Kondratov <a.kondratov@postgrespro.ru>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
	vladimirlesk@yandex-team.ru,
	Dmitriy Sarafannikov <dsarafan@yandex-team.ru>
Subject: Re: [Patch] pg_rewind: options to use restore_command from
 recovery.conf or command line
Message-ID: <20181022171907.ri2tkqtt7n6jm4dh@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <50b94dcb-c744-ff2c-d6a4-3c371f8a7f9a@postgrespro.ru>
User-Agent: NeoMutt/20180716
Precedence: bulk

On 2018-Oct-22, Alexey Kondratov 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 ... I don't see it in the postmaster
--help output.

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.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services