Re: pg_upgrade -u

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Ray Stell <stellr(at)vt(dot)edu>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_upgrade -u
Date: 2013-05-21 18:41:11
Message-ID: 20130521184111.GA1322@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, May 8, 2013 at 08:52:40PM -0400, Bruce Momjian wrote:
> On Wed, May 8, 2013 at 05:05:05PM -0400, Ray Stell wrote:
> > A minor detail in 9.2.4, but I noticed that the pg_upgrade flag for
> > superuser, -u, does not get carried to a -U flag on the vacuumdb commands
> > written to analyze_new_cluster.sh.
>
> OK, let me look at this issue.

I have thought about this and there are potentially several options
specified to pg_upgrade that could be passed into scripts:

-O, --new-options=OPTIONS new cluster options to pass to the server
-P, --new-port=NEWPORT new cluster port number (default 50432)
-u, --user=NAME cluster superuser (default "root")

However, if we pass these items into the scripts, we then force these
values to be used, even if the user wants to use a different value. It
is a balance between supplying defaults vs. requiring the user to supply
or change the values used during the ugprade.

At this point, I have favored _not_ supplying defaults in the script.
Do you have an alternative argument in favor of supplying defaults?

--
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

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Dev Kumkar 2013-05-21 18:58:48 Re: [GENERAL] ODBC constructs
Previous Message Moshe Jacobson 2013-05-21 18:39:57 Strange locking problem

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2013-05-21 20:33:17 Re: Fast promotion failure
Previous Message Fujii Masao 2013-05-21 18:16:53 pg_export_snapshot on standby side