On Wednesday, February 8, 2017 1:05:08 AM CET Tom Lane wrote:
> Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:
> > On 2/7/17 11:21 AM, Tom Lane wrote:
> >> A compromise that might be worth considering is to introduce
> >> into pg_config_manual.h, which would at least give you a reasonably
> >> stable target point for a long-lived patch.
> > You'd still need to patch postgresql.conf.sample somehow.
> Right.  The compromise position that I had in mind was to add the
> #define in pg_config_manual.h and teach initdb to propagate it into
> the installed copy of postgresql.conf, as we've done with other GUCs
> with platform-dependent defaults, such as backend_flush_after.
> That still leaves the question of what to do with the SGML docs.
> We could add some weasel wording to the effect that the default might
> be platform-specific, or we could leave the docs alone and expect the
> envisioned Red Hat patch to patch config.sgml along with
> pg_config_manual.h.

Thanks for quickt feedback.  Just to not give up too early, I'm attaching
2nd iteration.  I'm fine to fallback to pg_config_manual.h solution though,
if this is considered too bad.

I tried to fix the docs now (crucial part indeed) so we are not that
"scrict" and there's some space for per-distributor change of ssl_ciphers

>From the previous mail:
> I'm not really sure that we want to carry around that much baggage for a
> single-system hack.

Accepted, but still I'm giving a chance.  OpenSSL maintainers predict this (or
something else in similar fashion) is going to be invented in OpenSSL upstream.
So there's still some potential in ./configure option.


> It looks like the xxx_flush_after GUCs aren't exactly fully documented
> as to this point, so we have some work to do there too :-(

>                       regards, tom lane

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to