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.2070...@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
