пн, 21 янв. 2019 г. в 13:42, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com>:
>
> When libpq is loaded in the server (libpqwalreceiver, dblink,
> postgres_fdw), it may use libpq environment variables set in the
> postmaster environment for connection parameter defaults. I have
> noticed that this has some confusing effects in our test suites. I
> wonder if this is a good idea in general.
>
> For example, the TAP test infrastructure sets PGAPPNAME to allow
> identifying clients in the server log. But this environment variable is
> also inherited by temporary servers started with pg_ctl and is then in
> turn used by libpqwalreceiver as the application_name for connecting to
> remote servers where it then shows up in pg_stat_replication and is
> relevant for things like synchronous_standby_names.
>
> Also, the pg_rewind tests appear to rely implicitly on PGHOST and PGPORT
> being set in the server environment to find the other node via
> primary_conninfo. That is easy to fix, but it shows that this kind of
> thing can creep in unintentionally.
>
> I was thinking that maybe we should clear all libpq environment
> variables in the server, or perhaps have a mode in libpq to ignore all
> environment variables. Then again, maybe setting something like
> PGSSLMODE globally in the server could be useful, so just removing
> everything might not be the right answer.
As an author of the C++ client API (Pgfe) that currently wraps libpq I
would like
to ignore all these environment variables that affects libpq's behavior, because
libpq is an implementation detail and the Pgfe API hides it
completely. So +1 from
me for such a mode in libpq.