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