Horton
Menu

Thread

  1. pg_upgrade does not completely honor --new-port

    Devrim Gündüz <devrim@gunduz.org> — 2012-09-25T14:36:54Z

    Hi,

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?

Also, is it worth to add the value specified in --new-bindir as a prefix
to vacuumdb command in the same script?

Regards,
-- 
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

  2. Re: pg_upgrade does not completely honor --new-port

    Bruce Momjian <bruce@momjian.us> — 2012-09-27T02:06:50Z

    On Tue, Sep 25, 2012 at 05:36:54PM +0300, Devrim Gunduz wrote:
> 
> Hi,
> 
> 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?

> Also, is it worth to add the value specified in --new-bindir as a prefix
> to vacuumdb command in the same script?

Wow, I never thought of adding a path to those scripts, but it certainly
makes sense.  I have created the attached patch which does this.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  3. Re: pg_upgrade does not completely honor --new-port

    Bruce Momjian <bruce@momjian.us> — 2012-10-03T01:18:52Z

    Applied to head and 9.2.

---------------------------------------------------------------------------

On Wed, Sep 26, 2012 at 10:06:50PM -0400, Bruce Momjian wrote:
> On Tue, Sep 25, 2012 at 05:36:54PM +0300, Devrim Gunduz wrote:
> > 
> > Hi,
> > 
> > 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?
> 
> > Also, is it worth to add the value specified in --new-bindir as a prefix
> > to vacuumdb command in the same script?
> 
> Wow, I never thought of adding a path to those scripts, but it certainly
> makes sense.  I have created the attached patch which does this.
> 
> -- 
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com
> 
>   + It's impossible for everything to be true. +

> diff --git a/contrib/pg_upgrade/check.c b/contrib/pg_upgrade/check.c
> index bed10f8..2785eb7 100644
> --- a/contrib/pg_upgrade/check.c
> +++ b/contrib/pg_upgrade/check.c
> @@ -477,7 +477,7 @@ create_script_for_cluster_analyze(char **analyze_script_file_name)
>  			ECHO_QUOTE, ECHO_QUOTE);
>  	fprintf(script, "echo %sthis script and run:%s\n",
>  			ECHO_QUOTE, ECHO_QUOTE);
> -	fprintf(script, "echo %s    vacuumdb --all %s%s\n", ECHO_QUOTE,
> +	fprintf(script, "echo %s    \"%s/vacuumdb\" --all %s%s\n", ECHO_QUOTE, new_cluster.bindir,
>  	/* Did we copy the free space files? */
>  			(GET_MAJOR_VERSION(old_cluster.major_version) >= 804) ?
>  			"--analyze-only" : "--analyze", ECHO_QUOTE);
> @@ -498,7 +498,7 @@ create_script_for_cluster_analyze(char **analyze_script_file_name)
>  			ECHO_QUOTE, ECHO_QUOTE);
>  	fprintf(script, "echo %s--------------------------------------------------%s\n",
>  			ECHO_QUOTE, ECHO_QUOTE);
> -	fprintf(script, "vacuumdb --all --analyze-only\n");
> +	fprintf(script, "\"%s/vacuumdb\" --all --analyze-only\n", new_cluster.bindir);
>  	fprintf(script, "echo%s\n", ECHO_BLANK);
>  	fprintf(script, "echo %sThe server is now available with minimal optimizer statistics.%s\n",
>  			ECHO_QUOTE, ECHO_QUOTE);
> @@ -519,7 +519,7 @@ create_script_for_cluster_analyze(char **analyze_script_file_name)
>  			ECHO_QUOTE, ECHO_QUOTE);
>  	fprintf(script, "echo %s---------------------------------------------------%s\n",
>  			ECHO_QUOTE, ECHO_QUOTE);
> -	fprintf(script, "vacuumdb --all --analyze-only\n");
> +	fprintf(script, "\"%s/vacuumdb\" --all --analyze-only\n", new_cluster.bindir);
>  	fprintf(script, "echo%s\n\n", ECHO_BLANK);
>  
>  #ifndef WIN32
> @@ -532,7 +532,7 @@ create_script_for_cluster_analyze(char **analyze_script_file_name)
>  			ECHO_QUOTE, ECHO_QUOTE);
>  	fprintf(script, "echo %s-------------------------------------------------------------%s\n",
>  			ECHO_QUOTE, ECHO_QUOTE);
> -	fprintf(script, "vacuumdb --all %s\n",
> +	fprintf(script, "\"%s/vacuumdb\" --all %s\n", new_cluster.bindir,
>  	/* Did we copy the free space files? */
>  			(GET_MAJOR_VERSION(old_cluster.major_version) >= 804) ?
>  			"--analyze-only" : "--analyze");

> 
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers


-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  4. Re: pg_upgrade does not completely honor --new-port

    Devrim Gündüz <devrim@gunduz.org> — 2012-10-03T20:00:16Z

    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.

Regards,

-- 
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

  5. Re: pg_upgrade does not completely honor --new-port

    Alvaro Herrera <alvherre@2ndquadrant.com> — 2012-10-03T20:16:55Z

    Excerpts from Devrim GÜNDÜZ's message of mié oct 03 17:00:16 -0300 2012:
> 
> 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, you could have the script set the port number only if the variable
is not set from the calling shell ... you know,
PGPORT=${PGPORT:=the_other_number} .  That way, if the user wants to
specify a different port, they have to set PGPORT before calling the
script.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

  6. Re: pg_upgrade does not completely honor --new-port

    Bruce Momjian <bruce@momjian.us> — 2012-10-03T20:20:27Z

    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  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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

  7. Re: pg_upgrade does not completely honor --new-port

    Bruce Momjian <bruce@momjian.us> — 2012-10-03T20:23:39Z

    On Wed, Oct  3, 2012 at 05:16:55PM -0300, Alvaro Herrera wrote:
> Excerpts from Devrim GÜNDÜZ's message of mié oct 03 17:00:16 -0300 2012:
> > 
> > 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, you could have the script set the port number only if the variable
> is not set from the calling shell ... you know,
> PGPORT=${PGPORT:=the_other_number} .  That way, if the user wants to
> specify a different port, they have to set PGPORT before calling the
> script.

Good idea, but that is only going to work on Unix, and in fact only
using certain shells.  I don't think we want to go there, do we?  I
could expand that out to a normal shell _if_ statement, but again, only
works on Unix.

What we _could_ do is to add a comment line at the top that defines a
string that can be supplied, and default it to the port number;  that
would work on Unix and Windows, e.g.

	# uncomment and adjust if you want a special port number
	# PGPORT_STR="-p 5435"
	# export PGPORT

For Windows it would be "REM".  Is everyone happy with that?

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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