Thread: pg_upgrade -u
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.
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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On May 21, 2013, at 2:41 PM, Bruce Momjian wrote: > 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? Well, the story really began when I ran initdb with a -U arg. vacuumdb takes the -U also, but pg_upgrade does not. It seems like if I have to supply a -u in order to get pg_upgrade to function in the case where there is no default superuserin the cluster, then an associated vacuumdb command requires a -U arg. Perhaps just documenting the behavior is all that is needed, but -U is everywhere and I think that's a good thing.
On 5/21/13 2:41 PM, Bruce Momjian wrote: > 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? You could put environment variable assignments at the top of the script, so they are easy to change or remove. But it seems to me the values should be in there somehow.
On Wed, May 29, 2013 at 09:42:12AM -0400, Peter Eisentraut wrote:
> On 5/21/13 2:41 PM, Bruce Momjian wrote:
> > 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?
>
> You could put environment variable assignments at the top of the script,
> so they are easy to change or remove. But it seems to me the values
> should be in there somehow.
Yes, that was another option, though I am worried that I am going to
start getting script-specific, no? Can I just do this:
PGUSER="postgres"
export PGUSER
vacuumedb -U "$PGUSER"
Is that portable? I know I can't do:
export PGUSER="postgres"
as older shells can't process that. What about -P? Do I pass that too?
I now realize we can't pass -O.
This is all easy to do for 9.4 if we can just agree on it.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +