On Wed, Oct 3, 2012 at 11:00:16PM +0300, Devrim Gunduz wrote: > > Hi, > > On Wed, 2012-09-26 at 22:06 -0400, Bruce Momjian wrote: > > > > I just performed a test upgrade from 9.1 to 9.2, and used > > > --new-port variable. However, the analyze_new_cluster.sh does not > > > include the new port, thus when I run it, it fails. Any chance to > > > add the port number to the script? > > > > Well, the reason people normally use the port number is to do a live > > check, but obviously when the script is created it isn't doing a > > check. I am worried that if I do embed the port number in there, then > > if they change the port after the upgrade, they now can't use the > > script. I assume users would have PGPORT set before running the > > script, no? > > They can't use the script in each way -- at least we can make it usable > for one case, I think.
Well, my assumption is that they are unlikely to move the old _binary_ directory, but they are more likely to change the port number. My point is that if they change the port number to the default from a non-default, or they set the PGPORT environment variable, the script will work. If we hard-code the port, it would not work. In fact, pg_upgrade defaults to use port 50432 if they don't supply one. We would embed the port number only if they supplied a custom port number, but again, they might change that before going live with the new server. I guess I am confused why you would use pg_upgrade, and start the new server on a non-default port that isn't the same as PGPORT. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
