Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > A larger question is whether we should just disable all the checks for
> > environment variables. The C comment says:
>
> > * check_for_libpq_envvars()
> > *
> > * tests whether any libpq environment variables are set.
> > * Since pg_upgrade connects to both the old and the new server,
> > * it is potentially dangerous to have any of these set.
> > *
> > * If any are found, will log them and cancel.
>
> > I am not sure what to do.
>
> Well, the risk mentioned in that comment certainly seems real.
>
> An alternative solution that might be more user-friendly is to ensure
> that the connection strings pg_upgrade uses specify all important
> options, leaving nothing to be overridden by environment variables.
> Then you don't need to make the user adjust his environment.
Well, they can use the same port number for both servers. In fact I
just use the compiled-default of 5432 when I am testing. No reason they
could not supply value in an environment variable but it would have to
be the same for old and new server (the two servers never run at the
same time).
> Or you could just "unsetenv" instead of complaining.
I think it is really PGDATA that we certainly can't inherit from an
environment variable.
> I would like to think that eventually pg_upgrade won't start a
> postmaster at all, but connect using something more like a standalone
> backend. So someday the issue might go away --- but that someday
> isn't especially close.
That standalone backend is going to have to understand pg_dump SQL
output, with \connect, etc.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
