Re: pg_upgrade and PGPORT

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade and PGPORT
Date: 2011-05-11 18:26:29
Message-ID: 201105111826.p4BIQTs07182@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2011-05-11 18:28:45 Re: hint bit cache v5
Previous Message Tom Lane 2011-05-11 18:18:38 Re: pg_upgrade and PGPORT