On 2019-03-15 16:01, Noah Misch wrote:
{
local %ENV;
delete $ENV{PGAPPNAME};
...
}
>>>
>>> That doesn't work because the first line clears the entire environment.
>>
>> The solution to that is to do 'local %ENV = %ENV;', to assign a copy of
>> the original
On Fri, Mar 15, 2019 at 10:06:29AM +, Dagfinn Ilmari Mannsåker wrote:
> Peter Eisentraut writes:
>
> > On 2019-03-15 05:00, Noah Misch wrote:
> >> I consider the following style more idiomatic:
> >>
> >> {
> >> local %ENV;
> >> delete $ENV{PGAPPNAME};
> >> ...
> >> }
> >
> >
Peter Eisentraut writes:
> On 2019-03-15 05:00, Noah Misch wrote:
>> I consider the following style more idiomatic:
>>
>> {
>> local %ENV;
>> delete $ENV{PGAPPNAME};
>> ...
>> }
>
> That doesn't work because the first line clears the entire environment.
The solution to that is
On 2019-03-15 05:00, Noah Misch wrote:
> I consider the following style more idiomatic:
>
> {
> local %ENV;
> delete $ENV{PGAPPNAME};
> ...
> }
That doesn't work because the first line clears the entire environment.
What does work is
{
delete local $ENV{PGAPPNAME};
...
Looks good.
On Thu, Mar 14, 2019 at 12:06:45PM +0100, Peter Eisentraut wrote:
> + # Temporarily unset PGAPPNAME so that the server doesn't inherit
> + # it. Otherwise this could affect libpqwalreceiver connections in
> + # confusing ways.
> + my $save_pgappname = $ENV{PGAPPNAME};
On 2019-03-03 09:06, Noah Misch wrote:
> +1 for clearing PGAPPNAME before starting a test postmaster.
> I think this qualifies:
> env -i LANG=C "$(type -p pg_ctl)" -w restart -D "$PGDATA"
OK, let's make this simpler then. Here is an updated patch that just
unsets PGAPPNAME around pg_ctl invocati
On Mon, Jan 21, 2019 at 11:42:16AM +0100, Peter Eisentraut wrote:
> 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 lib
On 2019-01-21 11:42, Peter Eisentraut wrote:
> Maybe pg_ctl should have some functionality to clear the environment,
> and maybe there could be a facility in postgresql.conf to set
> environment variables.
After pondering this, this seemed to be the best solution.
Many init systems already clear
PORT
> 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 per
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
10 matches
Mail list logo
