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
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
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
пн, 21 янв. 2019 г. в 13:42, Peter Eisentraut
:
>
> 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
